diff mbox series

[v4,1/4] ethdev: add the API for getting burst mode information

Message ID 20191015075133.38560-2-haiyue.wang@intel.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series get Rx/Tx packet burst mode information |

Checks

Context Check Description
ci/iol-compilation success Compile Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Wang, Haiyue Oct. 15, 2019, 7:51 a.m. UTC 
  Some PMDs have more than one RX/TX burst paths, add the ethdev API
that allows an application to retrieve the mode information about
Rx/Tx packet burst such as Scalar or Vector, and Vector technology
like AVX2.

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
---
 doc/guides/nics/features.rst             | 11 ++++
 doc/guides/nics/features/default.ini     |  1 +
 doc/guides/rel_notes/release_19_11.rst   |  9 +++
 lib/librte_ethdev/rte_ethdev.c           | 83 ++++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev.h           | 82 +++++++++++++++++++++++
 lib/librte_ethdev/rte_ethdev_core.h      |  5 ++
 lib/librte_ethdev/rte_ethdev_version.map |  5 ++
 7 files changed, 196 insertions(+)

Comments

Ferruh Yigit Oct. 15, 2019, 10:45 a.m. UTC | #1 
On 10/15/2019 8:51 AM, Haiyue Wang wrote:
> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> that allows an application to retrieve the mode information about
> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> like AVX2.
> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>

<...>

> +/**
> + * Retrieve name about burst mode option.
> + *
> + * @param mode
> + *   The burst mode option of type *rte_eth_burst_mode_option*.
> + *
> + * @return
> + *   - "": Not found
> + *   - "xxx": name of the mode option.
> + */
> +__rte_experimental
> +const char *
> +rte_eth_burst_mode_option_name(uint64_t option);

Doxygen giving warnings [1], can be fixed [2] while merging.


[1]
.../lib/librte_ethdev/rte_ethdev.h:1217:
warning: Member rte_eth_burst_mode_option (enumeration) of file rte_ethdev.h is
not documented.

.../lib/librte_ethdev/rte_ethdev.h:3673:
warning: argument 'mode' of command @param is not found in the argument list of
rte_eth_burst_mode_option_name(uint64_t option)

.../lib/librte_ethdev/rte_ethdev.h:3685:
warning: The following parameters of rte_eth_burst_mode_option_name(uint64_t
option) are not documented:


[2]
 diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
 index 83b08ee4df..ec95f9b194 100644
 --- a/lib/librte_ethdev/rte_ethdev.h
 +++ b/lib/librte_ethdev/rte_ethdev.h
 @@ -1214,6 +1214,9 @@ struct rte_eth_txq_info {
         uint16_t nb_desc;           /**< configured number of TXDs. */
  } __rte_cache_min_aligned;

 +/**
 + * Burst mode types, values can be ORed to define the burst mode of a driver.
 + */
  enum rte_eth_burst_mode_option {
         RTE_ETH_BURST_SCALAR = (1 << 0),
         RTE_ETH_BURST_VECTOR = (1 << 1),
 @@ -3673,7 +3676,7 @@ int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t
 queue_id,
  /**
   * Retrieve name about burst mode option.
   *
 - * @param mode
 + * @param option
   *   The burst mode option of type *rte_eth_burst_mode_option*.
   *
   * @return
Ferruh Yigit Oct. 15, 2019, 11:13 a.m. UTC | #2 
On 10/15/2019 8:51 AM, Haiyue Wang wrote:
> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> that allows an application to retrieve the mode information about
> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> like AVX2.
> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Wang, Haiyue Oct. 15, 2019, 11:23 a.m. UTC | #3 
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, October 15, 2019 18:45
> To: Wang, Haiyue <haiyue.wang@intel.com>; dev@dpdk.org; Ye, Xiaolong <xiaolong.ye@intel.com>
> Cc: Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>; Sun,
> Chenmin <chenmin.sun@intel.com>
> Subject: Re: [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On 10/15/2019 8:51 AM, Haiyue Wang wrote:
> > Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > that allows an application to retrieve the mode information about
> > Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > like AVX2.
> >
> > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> 
> <...>
> 
> > +/**
> > + * Retrieve name about burst mode option.
> > + *
> > + * @param mode
> > + *   The burst mode option of type *rte_eth_burst_mode_option*.
> > + *
> > + * @return
> > + *   - "": Not found
> > + *   - "xxx": name of the mode option.
> > + */
> > +__rte_experimental
> > +const char *
> > +rte_eth_burst_mode_option_name(uint64_t option);
> 
> Doxygen giving warnings [1], can be fixed [2] while merging.
> 

Learned, thanks, will notice to check it next time. ;-)

> 
> [1]
> .../lib/librte_ethdev/rte_ethdev.h:1217:
> warning: Member rte_eth_burst_mode_option (enumeration) of file rte_ethdev.h is
> not documented.
> 
> .../lib/librte_ethdev/rte_ethdev.h:3673:
> warning: argument 'mode' of command @param is not found in the argument list of
> rte_eth_burst_mode_option_name(uint64_t option)
> 
> .../lib/librte_ethdev/rte_ethdev.h:3685:
> warning: The following parameters of rte_eth_burst_mode_option_name(uint64_t
> option) are not documented:
> 
> 
> [2]
>  diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>  index 83b08ee4df..ec95f9b194 100644
>  --- a/lib/librte_ethdev/rte_ethdev.h
>  +++ b/lib/librte_ethdev/rte_ethdev.h
>  @@ -1214,6 +1214,9 @@ struct rte_eth_txq_info {
>          uint16_t nb_desc;           /**< configured number of TXDs. */
>   } __rte_cache_min_aligned;
> 
>  +/**
>  + * Burst mode types, values can be ORed to define the burst mode of a driver.
>  + */
>   enum rte_eth_burst_mode_option {
>          RTE_ETH_BURST_SCALAR = (1 << 0),
>          RTE_ETH_BURST_VECTOR = (1 << 1),
>  @@ -3673,7 +3676,7 @@ int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t
>  queue_id,
>   /**
>    * Retrieve name about burst mode option.
>    *
>  - * @param mode
>  + * @param option
>    *   The burst mode option of type *rte_eth_burst_mode_option*.
>    *
>    * @return
Thomas Monjalon Oct. 25, 2019, 9:36 a.m. UTC | #4 
15/10/2019 09:51, Haiyue Wang:
> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> that allows an application to retrieve the mode information about
> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> like AVX2.

I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
Hopefully it is not too late to fix this API before releasing 19.11.

I think the idea of getting infos from PMD internal mode is not bad.
But I strongly disagree with standardizing the names. More below.

[...]
> +enum rte_eth_burst_mode_option {
> +	RTE_ETH_BURST_SCALAR = (1 << 0),
> +	RTE_ETH_BURST_VECTOR = (1 << 1),

2 bits for a boolean value?

> +
> +	/**< bits[15:2] are reserved for each vector type */
> +	RTE_ETH_BURST_ALTIVEC = (1 << 2),
> +	RTE_ETH_BURST_NEON = (1 << 3),
> +	RTE_ETH_BURST_SSE = (1 << 4),
> +	RTE_ETH_BURST_AVX2 = (1 << 5),
> +	RTE_ETH_BURST_AVX512 = (1 << 6),
> +
> +	RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */
> +	RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */
> +	RTE_ETH_BURST_SIMPLE = (1 << 18),

What means simple? Looks meaningless.

> +	RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */

What is per-queue burst? No need to add a comment if not adding any info.
The burst API is *already* per-queue.

> +};

How can we imagine standardizing the PMD optimizations?
PMD developers are free to have as many burst implementation as they want.
If we want to report info about what is used, it can be only a free string.

> +/**
> + * Ethernet device RX/TX queue packet burst mode information structure.
> + * Used to retrieve information about packet burst mode setting.
> + */
> +struct rte_eth_burst_mode {
> +	uint64_t options;
> +};

Why a struct for an integer?

> +/**
> + * Retrieve information about the Rx packet burst mode.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param queue_id
> + *   The Rx queue on the Ethernet device for which information
> + *   will be retrieved.
> + * @param mode
> + *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
> + *   with the information of the packet burst mode.

No reference to the enum rte_eth_burst_mode_option or RTE_ETH_BURST_ prefix?

> + *
> + * @return
> + *   - 0: Success
> + *   - -ENOTSUP: routine is not supported by the device PMD.
> + *   - -EINVAL:  The port_id or the queue_id is out of range.
> + */
> +__rte_experimental
> +int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> +	struct rte_eth_burst_mode *mode);
[...]
> +/**
> + * Retrieve name about burst mode option.
> + *
> + * @param mode
> + *   The burst mode option of type *rte_eth_burst_mode_option*.
> + *
> + * @return
> + *   - "": Not found
> + *   - "xxx": name of the mode option.
> + */
> +__rte_experimental
> +const char *
> +rte_eth_burst_mode_option_name(uint64_t option);

rte_eth_burst_mode_name would be a better function name.
But anyway, this function should not exist.
The string should be freely returned by the PMD
in the burst_mode_get functions.
Jerin Jacob Oct. 25, 2019, 10:26 a.m. UTC | #5 
On Fri, Oct 25, 2019 at 3:07 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 15/10/2019 09:51, Haiyue Wang:
> > Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > that allows an application to retrieve the mode information about
> > Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > like AVX2.
>
> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> Hopefully it is not too late to fix this API before releasing 19.11.
>
> I think the idea of getting infos from PMD internal mode is not bad.
> But I strongly disagree with standardizing the names. More below.

> How can we imagine standardizing the PMD optimizations?
> PMD developers are free to have as many burst implementation as they want.
> If we want to report info about what is used, it can be only a free string.

+1
Wang, Haiyue Oct. 25, 2019, 1:59 p.m. UTC | #6 
Hi Thomas & Andrew,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, October 25, 2019 17:37
> To: Wang, Haiyue <haiyue.wang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>;
> arybchenko@solarflare.com; viacheslavo@mellanox.com; stephen@networkplumber.org;
> david.marchand@redhat.com; jerinj@marvell.com
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 15/10/2019 09:51, Haiyue Wang:
> > Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > that allows an application to retrieve the mode information about
> > Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > like AVX2.
> 
> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> Hopefully it is not too late to fix this API before releasing 19.11.
> 
> I think the idea of getting infos from PMD internal mode is not bad.
> But I strongly disagree with standardizing the names. More below.
> 
> [...]
> > +enum rte_eth_burst_mode_option {
> > +	RTE_ETH_BURST_SCALAR = (1 << 0),
> > +	RTE_ETH_BURST_VECTOR = (1 << 1),
> 
> 2 bits for a boolean value?
> 

They have the Boolean value, but prefer to keep bit opaque, then can
loop to access all the bits ...

> > +
> > +	/**< bits[15:2] are reserved for each vector type */
> > +	RTE_ETH_BURST_ALTIVEC = (1 << 2),
> > +	RTE_ETH_BURST_NEON = (1 << 3),
> > +	RTE_ETH_BURST_SSE = (1 << 4),
> > +	RTE_ETH_BURST_AVX2 = (1 << 5),
> > +	RTE_ETH_BURST_AVX512 = (1 << 6),
> > +
> > +	RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */
> > +	RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */
> > +	RTE_ETH_BURST_SIMPLE = (1 << 18),
> 
> What means simple? Looks meaningless.
> 

The below is the 'simple' code, yes, not a good name, will try to extract
more generic name.

	/* Use a simple Tx queue if possible (only fast free is allowed) */
	ad->tx_simple_allowed =
		(txq->offloads ==
		(txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE) &&
		txq->tx_rs_thresh >= ICE_TX_MAX_BURST);


> > +	RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */
> 
> What is per-queue burst? No need to add a comment if not adding any info.
> The burst API is *already* per-queue.
> 

Not for this *burst API* per-queue, but for 'dev->rx/tx_pkt_burst', if the
PMD can do burst selection per-queue internally, like NOT ALL VECTOR / SCALAR.

> > +};
> 
> How can we imagine standardizing the PMD optimizations?
> PMD developers are free to have as many burst implementation as they want.
> If we want to report info about what is used, it can be only a free string.
> 
> > +/**
> > + * Ethernet device RX/TX queue packet burst mode information structure.
> > + * Used to retrieve information about packet burst mode setting.
> > + */
> > +struct rte_eth_burst_mode {
> > +	uint64_t options;
> > +};
> 
> Why a struct for an integer?
> 

For expanding the information for mode, don't have to change the API parameters.

> > +/**
> > + * Retrieve information about the Rx packet burst mode.
> > + *
> > + * @param port_id
> > + *   The port identifier of the Ethernet device.
> > + * @param queue_id
> > + *   The Rx queue on the Ethernet device for which information
> > + *   will be retrieved.
> > + * @param mode
> > + *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
> > + *   with the information of the packet burst mode.
> 
> No reference to the enum rte_eth_burst_mode_option or RTE_ETH_BURST_ prefix?
> 
> > + *
> > + * @return
> > + *   - 0: Success
> > + *   - -ENOTSUP: routine is not supported by the device PMD.
> > + *   - -EINVAL:  The port_id or the queue_id is out of range.
> > + */
> > +__rte_experimental
> > +int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> > +	struct rte_eth_burst_mode *mode);
> [...]
> > +/**
> > + * Retrieve name about burst mode option.
> > + *
> > + * @param mode
> > + *   The burst mode option of type *rte_eth_burst_mode_option*.
> > + *
> > + * @return
> > + *   - "": Not found
> > + *   - "xxx": name of the mode option.
> > + */
> > +__rte_experimental
> > +const char *
> > +rte_eth_burst_mode_option_name(uint64_t option);
> 
> rte_eth_burst_mode_name would be a better function name.
> But anyway, this function should not exist.
> The string should be freely returned by the PMD
> in the burst_mode_get functions.
> 

Design like : common part (options: vector, AVX2 etc) + device specific ?

struct rte_eth_burst_mode {
	uint64_t options;
	char dev_specific[128]; /* PMD has specific burst mode information */
};

Then rte_eth_burst_mode_option_name is good name to keep its small scope
on *options* stringification.
Ferruh Yigit Oct. 25, 2019, 2:08 p.m. UTC | #7 
On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> 15/10/2019 09:51, Haiyue Wang:
>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>> that allows an application to retrieve the mode information about
>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>> like AVX2.
> 
> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.

It has been discussed in the mail list and went through multiple discussions,
patch is out since the August, +1 to cc all maintainers I missed that part,
but when the patch is reviewed and there is no objection, why block the merge?

> Hopefully it is not too late to fix this API before releasing 19.11.
> 
> I think the idea of getting infos from PMD internal mode is not bad.
> But I strongly disagree with standardizing the names. More below.
> 
> [...]
>> +enum rte_eth_burst_mode_option {
>> +	RTE_ETH_BURST_SCALAR = (1 << 0),
>> +	RTE_ETH_BURST_VECTOR = (1 << 1),
> 
> 2 bits for a boolean value?
> 
>> +
>> +	/**< bits[15:2] are reserved for each vector type */
>> +	RTE_ETH_BURST_ALTIVEC = (1 << 2),
>> +	RTE_ETH_BURST_NEON = (1 << 3),
>> +	RTE_ETH_BURST_SSE = (1 << 4),
>> +	RTE_ETH_BURST_AVX2 = (1 << 5),
>> +	RTE_ETH_BURST_AVX512 = (1 << 6),
>> +
>> +	RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */
>> +	RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */
>> +	RTE_ETH_BURST_SIMPLE = (1 << 18),
> 
> What means simple? Looks meaningless.

It is used in some drivers as simple scalar path with most features are missing.

> 
>> +	RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */
> 
> What is per-queue burst? No need to add a comment if not adding any info.
> The burst API is *already* per-queue.

That was a comment by me, most PMDs doesn't support different vector path per
queue, for those PMDs, to make application life easy PMD can say if it supports
per queue or not with this flag.
If PMD supports only per port data path, application doesn't need to call this
per queue if it want.

> 
>> +};
> 
> How can we imagine standardizing the PMD optimizations?
> PMD developers are free to have as many burst implementation as they want.
> If we want to report info about what is used, it can be only a free string.

The main target of the API is to define the vector path, not all optimizations,
so the number is limited.

When there is a standardized output it can be easier to be consumed by the
applications.

> 
>> +/**
>> + * Ethernet device RX/TX queue packet burst mode information structure.
>> + * Used to retrieve information about packet burst mode setting.
>> + */
>> +struct rte_eth_burst_mode {
>> +	uint64_t options;
>> +};
> 
> Why a struct for an integer?

Again by a request from me, to not need to break the API if we need to add more
thing in the future.

> 
>> +/**
>> + * Retrieve information about the Rx packet burst mode.
>> + *
>> + * @param port_id
>> + *   The port identifier of the Ethernet device.
>> + * @param queue_id
>> + *   The Rx queue on the Ethernet device for which information
>> + *   will be retrieved.
>> + * @param mode
>> + *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
>> + *   with the information of the packet burst mode.
> 
> No reference to the enum rte_eth_burst_mode_option or RTE_ETH_BURST_ prefix?
> 
>> + *
>> + * @return
>> + *   - 0: Success
>> + *   - -ENOTSUP: routine is not supported by the device PMD.
>> + *   - -EINVAL:  The port_id or the queue_id is out of range.
>> + */
>> +__rte_experimental
>> +int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
>> +	struct rte_eth_burst_mode *mode);
> [...]
>> +/**
>> + * Retrieve name about burst mode option.
>> + *
>> + * @param mode
>> + *   The burst mode option of type *rte_eth_burst_mode_option*.
>> + *
>> + * @return
>> + *   - "": Not found
>> + *   - "xxx": name of the mode option.
>> + */
>> +__rte_experimental
>> +const char *
>> +rte_eth_burst_mode_option_name(uint64_t option);
> 
> rte_eth_burst_mode_name would be a better function name.
> But anyway, this function should not exist.
> The string should be freely returned by the PMD
> in the burst_mode_get functions.
Thomas Monjalon Oct. 25, 2019, 3:45 p.m. UTC | #8 
25/10/2019 16:08, Ferruh Yigit:
> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > 15/10/2019 09:51, Haiyue Wang:
> >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >> that allows an application to retrieve the mode information about
> >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >> like AVX2.
> > 
> > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> 
> It has been discussed in the mail list and went through multiple discussions,
> patch is out since the August, +1 to cc all maintainers I missed that part,
> but when the patch is reviewed and there is no objection, why block the merge?

I'm not saying blocking the merge.
My bad is that I missed the patch and I am asking for help with a notification
in this case. Same for Andrew I guess.
Note: it is merged in master and I am looking to improve this feature.

> > Hopefully it is not too late to fix this API before releasing 19.11.
> > 
> > I think the idea of getting infos from PMD internal mode is not bad.
> > But I strongly disagree with standardizing the names. More below.
> > 
> > [...]
> >> +enum rte_eth_burst_mode_option {
> >> +	RTE_ETH_BURST_SCALAR = (1 << 0),
> >> +	RTE_ETH_BURST_VECTOR = (1 << 1),
> > 
> > 2 bits for a boolean value?
> > 
> >> +
> >> +	/**< bits[15:2] are reserved for each vector type */
> >> +	RTE_ETH_BURST_ALTIVEC = (1 << 2),
> >> +	RTE_ETH_BURST_NEON = (1 << 3),
> >> +	RTE_ETH_BURST_SSE = (1 << 4),
> >> +	RTE_ETH_BURST_AVX2 = (1 << 5),
> >> +	RTE_ETH_BURST_AVX512 = (1 << 6),
> >> +
> >> +	RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */
> >> +	RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */
> >> +	RTE_ETH_BURST_SIMPLE = (1 << 18),
> > 
> > What means simple? Looks meaningless.
> 
> It is used in some drivers as simple scalar path with most features are missing.

This is a weak definition...

> >> +	RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */
> > 
> > What is per-queue burst? No need to add a comment if not adding any info.
> > The burst API is *already* per-queue.
> 
> That was a comment by me, most PMDs doesn't support different vector path per
> queue, for those PMDs, to make application life easy PMD can say if it supports
> per queue or not with this flag.
> If PMD supports only per port data path, application doesn't need to call this
> per queue if it want.

It would require some doxygen explanations.

> >> +};
> > 
> > How can we imagine standardizing the PMD optimizations?
> > PMD developers are free to have as many burst implementation as they want.
> > If we want to report info about what is used, it can be only a free string.
> 
> The main target of the API is to define the vector path, not all optimizations,
> so the number is limited.
> 
> When there is a standardized output it can be easier to be consumed by the
> applications.

Why application needs this info to be standardized?
I think it should not. I am really against such standardization.
I think it would hurt more than help because there are a lot more
major infos than just knowing the ISA it is using.

I think such info should be used only for debugging or have a clue
about the expected performance.
You cannot standardize the expectations of a specific implementation.

> >> +/**
> >> + * Ethernet device RX/TX queue packet burst mode information structure.
> >> + * Used to retrieve information about packet burst mode setting.
> >> + */
> >> +struct rte_eth_burst_mode {
> >> +	uint64_t options;
> >> +};
> > 
> > Why a struct for an integer?
> 
> Again by a request from me, to not need to break the API if we need to add more
> thing in the future.

I would replace it with a string. This is the most flexible API.

> >> +/**
> >> + * Retrieve information about the Rx packet burst mode.
> >> + *
> >> + * @param port_id
> >> + *   The port identifier of the Ethernet device.
> >> + * @param queue_id
> >> + *   The Rx queue on the Ethernet device for which information
> >> + *   will be retrieved.
> >> + * @param mode
> >> + *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
> >> + *   with the information of the packet burst mode.
> > 
> > No reference to the enum rte_eth_burst_mode_option or RTE_ETH_BURST_ prefix?
> > 
> >> + *
> >> + * @return
> >> + *   - 0: Success
> >> + *   - -ENOTSUP: routine is not supported by the device PMD.
> >> + *   - -EINVAL:  The port_id or the queue_id is out of range.
> >> + */
> >> +__rte_experimental
> >> +int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> >> +	struct rte_eth_burst_mode *mode);
> > [...]
> >> +/**
> >> + * Retrieve name about burst mode option.
> >> + *
> >> + * @param mode
> >> + *   The burst mode option of type *rte_eth_burst_mode_option*.
> >> + *
> >> + * @return
> >> + *   - "": Not found
> >> + *   - "xxx": name of the mode option.
> >> + */
> >> +__rte_experimental
> >> +const char *
> >> +rte_eth_burst_mode_option_name(uint64_t option);
> > 
> > rte_eth_burst_mode_name would be a better function name.
> > But anyway, this function should not exist.
> > The string should be freely returned by the PMD
> > in the burst_mode_get functions.
Jerin Jacob Oct. 25, 2019, 4:02 p.m. UTC | #9 
On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 25/10/2019 16:08, Ferruh Yigit:
> > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > 15/10/2019 09:51, Haiyue Wang:
> > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > >> that allows an application to retrieve the mode information about
> > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > >> like AVX2.
> > >
> > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >
> > It has been discussed in the mail list and went through multiple discussions,
> > patch is out since the August, +1 to cc all maintainers I missed that part,
> > but when the patch is reviewed and there is no objection, why block the merge?
>
> I'm not saying blocking the merge.
> My bad is that I missed the patch and I am asking for help with a notification
> in this case. Same for Andrew I guess.
> Note: it is merged in master and I am looking to improve this feature.
>

> > >> +/**
> > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > >> + * Used to retrieve information about packet burst mode setting.
> > >> + */
> > >> +struct rte_eth_burst_mode {
> > >> +  uint64_t options;
> > >> +};
> > >
> > > Why a struct for an integer?
> >
> > Again by a request from me, to not need to break the API if we need to add more
> > thing in the future.
>
> I would replace it with a string. This is the most flexible API.

IMO, Probably, best of both worlds make a good option here,
as Haiyue suggested if we have an additional dev_specific[1] in structure.
and when a pass to the application, let common code make final string as
(options flags to string + dev_specific)

options flag can be zero if PMD does not have any generic flags nor
interested in such a scheme.
Generic flags will help at least to have some common code.

[1]
struct rte_eth_burst_mode {
        uint64_t options;
        char dev_specific[128]; /* PMD has specific burst mode information */
};
Thomas Monjalon Oct. 25, 2019, 10:27 p.m. UTC | #10 
25/10/2019 18:02, Jerin Jacob:
> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 25/10/2019 16:08, Ferruh Yigit:
> > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > 15/10/2019 09:51, Haiyue Wang:
> > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > >> that allows an application to retrieve the mode information about
> > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > >> like AVX2.
> > > >
> > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > >
> > > It has been discussed in the mail list and went through multiple discussions,
> > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > but when the patch is reviewed and there is no objection, why block the merge?
> >
> > I'm not saying blocking the merge.
> > My bad is that I missed the patch and I am asking for help with a notification
> > in this case. Same for Andrew I guess.
> > Note: it is merged in master and I am looking to improve this feature.
> 
> > > >> +/**
> > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > >> + * Used to retrieve information about packet burst mode setting.
> > > >> + */
> > > >> +struct rte_eth_burst_mode {
> > > >> +  uint64_t options;
> > > >> +};
> > > >
> > > > Why a struct for an integer?
> > >
> > > Again by a request from me, to not need to break the API if we need to add more
> > > thing in the future.
> >
> > I would replace it with a string. This is the most flexible API.
> 
> IMO, Probably, best of both worlds make a good option here,
> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> and when a pass to the application, let common code make final string as
> (options flags to string + dev_specific)
> 
> options flag can be zero if PMD does not have any generic flags nor
> interested in such a scheme.
> Generic flags will help at least to have some common code.
> 
> [1]
> struct rte_eth_burst_mode {
>         uint64_t options;
>         char dev_specific[128]; /* PMD has specific burst mode information */
> };

I really don't see how we can have generic flags.
The flags which are proposed are just matching
the functions implemented in Intel PMDs.
And this is a complicate solution.
Why not just returning a name for the selected Rx/Tx mode?
Wang, Haiyue Oct. 26, 2019, 4:40 a.m. UTC | #11 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Saturday, October 26, 2019 06:27
> To: Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 25/10/2019 18:02, Jerin Jacob:
> > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > 25/10/2019 16:08, Ferruh Yigit:
> > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > >> that allows an application to retrieve the mode information about
> > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > >> like AVX2.
> > > > >
> > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > >
> > > > It has been discussed in the mail list and went through multiple discussions,
> > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > but when the patch is reviewed and there is no objection, why block the merge?
> > >
> > > I'm not saying blocking the merge.
> > > My bad is that I missed the patch and I am asking for help with a notification
> > > in this case. Same for Andrew I guess.
> > > Note: it is merged in master and I am looking to improve this feature.
> >
> > > > >> +/**
> > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > >> + */
> > > > >> +struct rte_eth_burst_mode {
> > > > >> +  uint64_t options;
> > > > >> +};
> > > > >
> > > > > Why a struct for an integer?
> > > >
> > > > Again by a request from me, to not need to break the API if we need to add more
> > > > thing in the future.
> > >
> > > I would replace it with a string. This is the most flexible API.
> >
> > IMO, Probably, best of both worlds make a good option here,
> > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > and when a pass to the application, let common code make final string as
> > (options flags to string + dev_specific)
> >
> > options flag can be zero if PMD does not have any generic flags nor
> > interested in such a scheme.
> > Generic flags will help at least to have some common code.
> >
> > [1]
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> >         char dev_specific[128]; /* PMD has specific burst mode information */
> > };
> 
> I really don't see how we can have generic flags.
> The flags which are proposed are just matching
> the functions implemented in Intel PMDs.
> And this is a complicate solution.
> Why not just returning a name for the selected Rx/Tx mode?
> 

Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
that consists of libraries to accelerate packet processing workloads running on a wide
variety of CPU architectures."

If understand these new experimental APIs from above, then bit options is the best,
and we didn't invent new words to describe them, just from the CPU & other *generic*
technology. And the application can loop to check which kind of burst is running by
just simple bit test.

If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
like MLX5 supports ARM NEON, x86 SSE.
Thomas Monjalon Oct. 26, 2019, 6:24 a.m. UTC | #12 
26/10/2019 06:40, Wang, Haiyue:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 25/10/2019 18:02, Jerin Jacob:
> > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > > >> that allows an application to retrieve the mode information about
> > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > > >> like AVX2.
> > > > > >
> > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > > >
> > > > > It has been discussed in the mail list and went through multiple discussions,
> > > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > > but when the patch is reviewed and there is no objection, why block the merge?
> > > >
> > > > I'm not saying blocking the merge.
> > > > My bad is that I missed the patch and I am asking for help with a notification
> > > > in this case. Same for Andrew I guess.
> > > > Note: it is merged in master and I am looking to improve this feature.
> > >
> > > > > >> +/**
> > > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > >> + */
> > > > > >> +struct rte_eth_burst_mode {
> > > > > >> +  uint64_t options;
> > > > > >> +};
> > > > > >
> > > > > > Why a struct for an integer?
> > > > >
> > > > > Again by a request from me, to not need to break the API if we need to add more
> > > > > thing in the future.
> > > >
> > > > I would replace it with a string. This is the most flexible API.
> > >
> > > IMO, Probably, best of both worlds make a good option here,
> > > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > > and when a pass to the application, let common code make final string as
> > > (options flags to string + dev_specific)
> > >
> > > options flag can be zero if PMD does not have any generic flags nor
> > > interested in such a scheme.
> > > Generic flags will help at least to have some common code.
> > >
> > > [1]
> > > struct rte_eth_burst_mode {
> > >         uint64_t options;
> > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > };
> > 
> > I really don't see how we can have generic flags.
> > The flags which are proposed are just matching
> > the functions implemented in Intel PMDs.
> > And this is a complicate solution.
> > Why not just returning a name for the selected Rx/Tx mode?
> 
> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> that consists of libraries to accelerate packet processing workloads running on a wide
> variety of CPU architectures."

How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
They just match some features of the Intel PMDs.
Why not exposing other optimizations of the Rx/Tx implementations?
You totally missed the point of generic burst mode description.

> If understand these new experimental APIs from above, then bit options is the best,
> and we didn't invent new words to describe them, just from the CPU & other *generic*
> technology. And the application can loop to check which kind of burst is running by
> just simple bit test.
> 
> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> like MLX5 supports ARM NEON, x86 SSE.

I have no word!
You really think other PMDs should learn from Intel how to "enhance" their PMD?
You talk about mlx5, did you look at its code? Did you see the burst modes
depending on which specific hardware path is used (MPRQ, EMPW, inline)?
Or depending on which offloads are handled?

Again, the instruction set used by the function is a small part
of the burst mode optimization.

So you did not reply to my question:
Why not just returning a name for the selected Rx/Tx mode?
Slava Ovsiienko Oct. 26, 2019, 6:40 a.m. UTC | #13 
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Saturday, October 26, 2019 1:27
> To: Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Haiyue Wang
> <haiyue.wang@intel.com>; dpdk-dev <dev@dpdk.org>;
> xiaolong.ye@intel.com; ray.kinsella@intel.com; Bernard Iremonger
> <bernard.iremonger@intel.com>; chenmin.sun@intel.com; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Jerin Jacob <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> mode information
> 
> 25/10/2019 18:02, Jerin Jacob:
> > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> <thomas@monjalon.net> wrote:
> > > 25/10/2019 16:08, Ferruh Yigit:
> > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > >> API that allows an application to retrieve the mode information
> > > > >> about Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > >> technology like AVX2.
> > > > >
> > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not
> CC'ed.
> > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before
> merging.
> > > >
> > > > It has been discussed in the mail list and went through multiple
> > > > discussions, patch is out since the August, +1 to cc all
> > > > maintainers I missed that part, but when the patch is reviewed and
> there is no objection, why block the merge?
> > >
> > > I'm not saying blocking the merge.
> > > My bad is that I missed the patch and I am asking for help with a
> > > notification in this case. Same for Andrew I guess.
> > > Note: it is merged in master and I am looking to improve this feature.
> >
> > > > >> +/**
> > > > >> + * Ethernet device RX/TX queue packet burst mode information
> structure.
> > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > >> + */
> > > > >> +struct rte_eth_burst_mode {
> > > > >> +  uint64_t options;
> > > > >> +};
> > > > >
> > > > > Why a struct for an integer?
> > > >
> > > > Again by a request from me, to not need to break the API if we
> > > > need to add more thing in the future.
> > >
> > > I would replace it with a string. This is the most flexible API.
> >
> > IMO, Probably, best of both worlds make a good option here, as Haiyue
> > suggested if we have an additional dev_specific[1] in structure.
> > and when a pass to the application, let common code make final string
> > as (options flags to string + dev_specific)
> >
> > options flag can be zero if PMD does not have any generic flags nor
> > interested in such a scheme.
> > Generic flags will help at least to have some common code.
> >
> > [1]
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> >         char dev_specific[128]; /* PMD has specific burst mode
> > information */ };
> 
> I really don't see how we can have generic flags.
> The flags which are proposed are just matching the functions implemented in
> Intel PMDs.
> And this is a complicate solution.
> Why not just returning a name for the selected Rx/Tx mode?
> 
+1
Just an example, mlx5 PMD now has  approx. 60 tx_burst routines and most of these ones
are not related to vectorized variations (but to tx offloads). Returning  the name would be more
flexible and informative. 

It is very common case to ask customer about which tx routine is engaged with particular settings,
now we have to ask to build the debug version and present the log.

With best regards, Slava
Jerin Jacob Oct. 26, 2019, 6:58 a.m. UTC | #14 
On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 25/10/2019 18:02, Jerin Jacob:
> > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > 25/10/2019 16:08, Ferruh Yigit:
> > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > >> that allows an application to retrieve the mode information about
> > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > >> like AVX2.
> > > > >
> > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > >
> > > > It has been discussed in the mail list and went through multiple discussions,
> > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > but when the patch is reviewed and there is no objection, why block the merge?
> > >
> > > I'm not saying blocking the merge.
> > > My bad is that I missed the patch and I am asking for help with a notification
> > > in this case. Same for Andrew I guess.
> > > Note: it is merged in master and I am looking to improve this feature.
> >
> > > > >> +/**
> > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > >> + */
> > > > >> +struct rte_eth_burst_mode {
> > > > >> +  uint64_t options;
> > > > >> +};
> > > > >
> > > > > Why a struct for an integer?
> > > >
> > > > Again by a request from me, to not need to break the API if we need to add more
> > > > thing in the future.
> > >
> > > I would replace it with a string. This is the most flexible API.
> >
> > IMO, Probably, best of both worlds make a good option here,
> > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > and when a pass to the application, let common code make final string as
> > (options flags to string + dev_specific)
> >
> > options flag can be zero if PMD does not have any generic flags nor
> > interested in such a scheme.
> > Generic flags will help at least to have some common code.
> >
> > [1]
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> >         char dev_specific[128]; /* PMD has specific burst mode information */
> > };
>
> I really don't see how we can have generic flags.
> The flags which are proposed are just matching
> the functions implemented in Intel PMDs.
> And this is a complicate solution.
> Why not just returning a name for the selected Rx/Tx mode?

+1 only for the name

Let me clarify my earlier proposal:

1) The public ethdev API should return only "string" i.e the flags
SHOULD NOT be exposed as ethdev API
i.e
int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);

2) The PMD interface  to the common code can be following

 struct eth_pmd_burst_mode {
        uint64_t options;
         char name[128]; /* PMD specific burst mode information */
};

typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
        uint16_t queue_id, struct eth_burst_mode *mode)

3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
flag to string converion(again internal to common code implemetation)
and concatenate with eth_pmd_burst_mode::name

This would help to reuse some of the flags to name conversion logic
across all PMDs.
And PMD are free to return  eth_pmd_burst_mode::options as zero in
that case final
string only be eth_pmd_burst_mode::name.

I don't see any downside with this approach and it best of both worlds.






>
>
Wang, Haiyue Oct. 26, 2019, 9:23 a.m. UTC | #15 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Saturday, October 26, 2019 14:24
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Jerin Jacob <jerinjacobk@gmail.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 26/10/2019 06:40, Wang, Haiyue:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 25/10/2019 18:02, Jerin Jacob:
> > > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > > > >> that allows an application to retrieve the mode information about
> > > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > > > >> like AVX2.
> > > > > > >
> > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > > > >
> > > > > > It has been discussed in the mail list and went through multiple discussions,
> > > > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > > > but when the patch is reviewed and there is no objection, why block the merge?
> > > > >
> > > > > I'm not saying blocking the merge.
> > > > > My bad is that I missed the patch and I am asking for help with a notification
> > > > > in this case. Same for Andrew I guess.
> > > > > Note: it is merged in master and I am looking to improve this feature.
> > > >
> > > > > > >> +/**
> > > > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > > >> + */
> > > > > > >> +struct rte_eth_burst_mode {
> > > > > > >> +  uint64_t options;
> > > > > > >> +};
> > > > > > >
> > > > > > > Why a struct for an integer?
> > > > > >
> > > > > > Again by a request from me, to not need to break the API if we need to add more
> > > > > > thing in the future.
> > > > >
> > > > > I would replace it with a string. This is the most flexible API.
> > > >
> > > > IMO, Probably, best of both worlds make a good option here,
> > > > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > > > and when a pass to the application, let common code make final string as
> > > > (options flags to string + dev_specific)
> > > >
> > > > options flag can be zero if PMD does not have any generic flags nor
> > > > interested in such a scheme.
> > > > Generic flags will help at least to have some common code.
> > > >
> > > > [1]
> > > > struct rte_eth_burst_mode {
> > > >         uint64_t options;
> > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > };
> > >
> > > I really don't see how we can have generic flags.
> > > The flags which are proposed are just matching
> > > the functions implemented in Intel PMDs.
> > > And this is a complicate solution.
> > > Why not just returning a name for the selected Rx/Tx mode?
> >
> > Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> > 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> > that consists of libraries to accelerate packet processing workloads running on a wide
> > variety of CPU architectures."
> 
> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> They just match some features of the Intel PMDs.
> Why not exposing other optimizations of the Rx/Tx implementations?
> You totally missed the point of generic burst mode description.
> 
> > If understand these new experimental APIs from above, then bit options is the best,
> > and we didn't invent new words to describe them, just from the CPU & other *generic*
> > technology. And the application can loop to check which kind of burst is running by
> > just simple bit test.
> >
> > If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> > like MLX5 supports ARM NEON, x86 SSE.
> 
> I have no word!
> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> You talk about mlx5, did you look at its code? Did you see the burst modes
> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> Or depending on which offloads are handled?
> 
> Again, the instruction set used by the function is a small part
> of the burst mode optimization.
> 
> So you did not reply to my question:
> Why not just returning a name for the selected Rx/Tx mode?
> 

In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
application to do further processing, strcmp, strstr ? Not so nice
for C code, and it is not so standard, So switch it to bit definition.

Well, the *name* here we used is CPU related, at least, it is common.
But not "specific hardware path is used (MPRQ, EMPW, inline)".

If the API is not bad, but the data is not so good, then accept below ? ;-)

struct eth_pmd_burst_mode {
        uint64_t options;  /* Generic vector etc. */
         char name[128]; /* PMD specific burst mode information */
};

===

https://patchwork.dpdk.org/patch/57626/
https://patchwork.dpdk.org/patch/57642/
https://patchwork.dpdk.org/patch/57644/


+int
+ice_rx_burst_info_get(struct rte_eth_dev *dev, __rte_unused uint16_t queue_id,
+		      char *buf, int sz)
+{
+	int len = 0;
+
+	if (dev->rx_pkt_burst == ice_recv_scattered_pkts)
+		len = snprintf(buf, sz, "Scattered Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts_bulk_alloc)
+		len = snprintf(buf, sz, "Bulk Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts)
+		len = snprintf(buf, sz, "Normal Rx");
+#ifdef RTE_ARCH_X86
+	else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
+		len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
+	else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
+		len = snprintf(buf, sz, "Vector Scattered Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
+		len = snprintf(buf, sz, "AVX2 Vector Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
+		len = snprintf(buf, sz, "Vector Rx");
+#endif
+
+	if (len >= sz)
+		len = -ENOSPC; /* The output was truncated */
+
+	return len;
+}
Wang, Haiyue Oct. 26, 2019, 9:31 a.m. UTC | #16 
> -----Original Message-----
> From: Slava Ovsiienko [mailto:viacheslavo@mellanox.com]
> Sent: Saturday, October 26, 2019 14:41
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Stephen Hemminger <stephen@networkplumber.org>; David Marchand
> <david.marchand@redhat.com>; Jerin Jacob <jerinj@marvell.com>
> Subject: RE: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Saturday, October 26, 2019 1:27
> > To: Jerin Jacob <jerinjacobk@gmail.com>
> > Cc: Ferruh Yigit <ferruh.yigit@intel.com>; Haiyue Wang
> > <haiyue.wang@intel.com>; dpdk-dev <dev@dpdk.org>;
> > xiaolong.ye@intel.com; ray.kinsella@intel.com; Bernard Iremonger
> > <bernard.iremonger@intel.com>; chenmin.sun@intel.com; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand
> > <david.marchand@redhat.com>; Jerin Jacob <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst
> > mode information
> >
> > 25/10/2019 18:02, Jerin Jacob:
> > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon
> > <thomas@monjalon.net> wrote:
> > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev
> > > > > >> API that allows an application to retrieve the mode information
> > > > > >> about Rx/Tx packet burst such as Scalar or Vector, and Vector
> > > > > >> technology like AVX2.
> > > > > >
> > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not
> > CC'ed.
> > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before
> > merging.
> > > > >
> > > > > It has been discussed in the mail list and went through multiple
> > > > > discussions, patch is out since the August, +1 to cc all
> > > > > maintainers I missed that part, but when the patch is reviewed and
> > there is no objection, why block the merge?
> > > >
> > > > I'm not saying blocking the merge.
> > > > My bad is that I missed the patch and I am asking for help with a
> > > > notification in this case. Same for Andrew I guess.
> > > > Note: it is merged in master and I am looking to improve this feature.
> > >
> > > > > >> +/**
> > > > > >> + * Ethernet device RX/TX queue packet burst mode information
> > structure.
> > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > >> + */
> > > > > >> +struct rte_eth_burst_mode {
> > > > > >> +  uint64_t options;
> > > > > >> +};
> > > > > >
> > > > > > Why a struct for an integer?
> > > > >
> > > > > Again by a request from me, to not need to break the API if we
> > > > > need to add more thing in the future.
> > > >
> > > > I would replace it with a string. This is the most flexible API.
> > >
> > > IMO, Probably, best of both worlds make a good option here, as Haiyue
> > > suggested if we have an additional dev_specific[1] in structure.
> > > and when a pass to the application, let common code make final string
> > > as (options flags to string + dev_specific)
> > >
> > > options flag can be zero if PMD does not have any generic flags nor
> > > interested in such a scheme.
> > > Generic flags will help at least to have some common code.
> > >
> > > [1]
> > > struct rte_eth_burst_mode {
> > >         uint64_t options;
> > >         char dev_specific[128]; /* PMD has specific burst mode
> > > information */ };
> >
> > I really don't see how we can have generic flags.
> > The flags which are proposed are just matching the functions implemented in
> > Intel PMDs.
> > And this is a complicate solution.
> > Why not just returning a name for the selected Rx/Tx mode?
> >
> +1
> Just an example, mlx5 PMD now has  approx. 60 tx_burst routines and most of these ones
> are not related to vectorized variations (but to tx offloads). Returning  the name would be more
> flexible and informative.
> 
> It is very common case to ask customer about which tx routine is engaged with particular settings,
> now we have to ask to build the debug version and present the log.
> 

Yes, this API is from that VPP can't get the static function by default compile options.
Current design is from CPU's view like vectorized, mbuf bulk allocation. We think it can
be bit data. Name is not good for this, you have to strcat them for different combinations.

But for hardware specific, name is a good one. We didn't design this API for this at
first. ;-)



> With best regards, Slava
Wang, Haiyue Oct. 26, 2019, 9:37 a.m. UTC | #17 
> -----Original Message-----
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Saturday, October 26, 2019 14:58
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 25/10/2019 18:02, Jerin Jacob:
> > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > > >> that allows an application to retrieve the mode information about
> > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > > >> like AVX2.
> > > > > >
> > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > > >
> > > > > It has been discussed in the mail list and went through multiple discussions,
> > > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > > but when the patch is reviewed and there is no objection, why block the merge?
> > > >
> > > > I'm not saying blocking the merge.
> > > > My bad is that I missed the patch and I am asking for help with a notification
> > > > in this case. Same for Andrew I guess.
> > > > Note: it is merged in master and I am looking to improve this feature.
> > >
> > > > > >> +/**
> > > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > >> + */
> > > > > >> +struct rte_eth_burst_mode {
> > > > > >> +  uint64_t options;
> > > > > >> +};
> > > > > >
> > > > > > Why a struct for an integer?
> > > > >
> > > > > Again by a request from me, to not need to break the API if we need to add more
> > > > > thing in the future.
> > > >
> > > > I would replace it with a string. This is the most flexible API.
> > >
> > > IMO, Probably, best of both worlds make a good option here,
> > > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > > and when a pass to the application, let common code make final string as
> > > (options flags to string + dev_specific)
> > >
> > > options flag can be zero if PMD does not have any generic flags nor
> > > interested in such a scheme.
> > > Generic flags will help at least to have some common code.
> > >
> > > [1]
> > > struct rte_eth_burst_mode {
> > >         uint64_t options;
> > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > };
> >
> > I really don't see how we can have generic flags.
> > The flags which are proposed are just matching
> > the functions implemented in Intel PMDs.
> > And this is a complicate solution.
> > Why not just returning a name for the selected Rx/Tx mode?
> 
> +1 only for the name
> 
> Let me clarify my earlier proposal:
> 
> 1) The public ethdev API should return only "string" i.e the flags
> SHOULD NOT be exposed as ethdev API
> i.e
> int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> 
> 2) The PMD interface  to the common code can be following
> 
>  struct eth_pmd_burst_mode {
>         uint64_t options;
>          char name[128]; /* PMD specific burst mode information */
> };
> 
> typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
>         uint16_t queue_id, struct eth_burst_mode *mode)
> 
> 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> flag to string converion(again internal to common code implemetation)
> and concatenate with eth_pmd_burst_mode::name
> 
> This would help to reuse some of the flags to name conversion logic
> across all PMDs.
> And PMD are free to return  eth_pmd_burst_mode::options as zero in
> that case final
> string only be eth_pmd_burst_mode::name.
> 

In fact, 'rte_eth_burst_mode_option_name' for single option, not
for struct eth_pmd_burst_mode::option[s]. Need loop to display them.


static void
burst_mode_options_display(uint64_t options)
{
	int offset;

	while (options != 0) {
		offset = rte_bsf64(options);

		printf(" %s",
		       rte_eth_burst_mode_option_name(1ULL << offset));

		options &= ~(1ULL << offset);
	}
}

But can change the name show like:

	if (rte_eth_tx_burst_mode_get(port_id, queue_id, &mode) == 0) {
		printf("\nBurst mode:");
		burst_mode_options_display(mode.options);

		if (mode.name[0] != '\0')
			printf("(%s)", mode.name); // use (...) to highlight device hardware specific.
	}

> I don't see any downside with this approach and it best of both worlds.
> 
> 
> 
> 
> 
> 
> >
> >
Thomas Monjalon Oct. 26, 2019, 4:23 p.m. UTC | #18 
26/10/2019 11:23, Wang, Haiyue:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 26/10/2019 06:40, Wang, Haiyue:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 25/10/2019 18:02, Jerin Jacob:
> > > > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > 25/10/2019 16:08, Ferruh Yigit:
> > > > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > > > > > > > 15/10/2019 09:51, Haiyue Wang:
> > > > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > > > > > > >> that allows an application to retrieve the mode information about
> > > > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > > > > > > >> like AVX2.
> > > > > > > >
> > > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > > > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > > > > > >
> > > > > > > It has been discussed in the mail list and went through multiple discussions,
> > > > > > > patch is out since the August, +1 to cc all maintainers I missed that part,
> > > > > > > but when the patch is reviewed and there is no objection, why block the merge?
> > > > > >
> > > > > > I'm not saying blocking the merge.
> > > > > > My bad is that I missed the patch and I am asking for help with a notification
> > > > > > in this case. Same for Andrew I guess.
> > > > > > Note: it is merged in master and I am looking to improve this feature.
> > > > >
> > > > > > > >> +/**
> > > > > > > >> + * Ethernet device RX/TX queue packet burst mode information structure.
> > > > > > > >> + * Used to retrieve information about packet burst mode setting.
> > > > > > > >> + */
> > > > > > > >> +struct rte_eth_burst_mode {
> > > > > > > >> +  uint64_t options;
> > > > > > > >> +};
> > > > > > > >
> > > > > > > > Why a struct for an integer?
> > > > > > >
> > > > > > > Again by a request from me, to not need to break the API if we need to add more
> > > > > > > thing in the future.
> > > > > >
> > > > > > I would replace it with a string. This is the most flexible API.
> > > > >
> > > > > IMO, Probably, best of both worlds make a good option here,
> > > > > as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > > > > and when a pass to the application, let common code make final string as
> > > > > (options flags to string + dev_specific)
> > > > >
> > > > > options flag can be zero if PMD does not have any generic flags nor
> > > > > interested in such a scheme.
> > > > > Generic flags will help at least to have some common code.
> > > > >
> > > > > [1]
> > > > > struct rte_eth_burst_mode {
> > > > >         uint64_t options;
> > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > };
> > > >
> > > > I really don't see how we can have generic flags.
> > > > The flags which are proposed are just matching
> > > > the functions implemented in Intel PMDs.
> > > > And this is a complicate solution.
> > > > Why not just returning a name for the selected Rx/Tx mode?
> > >
> > > Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> > > 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> > > that consists of libraries to accelerate packet processing workloads running on a wide
> > > variety of CPU architectures."
> > 
> > How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> > They just match some features of the Intel PMDs.
> > Why not exposing other optimizations of the Rx/Tx implementations?
> > You totally missed the point of generic burst mode description.
> > 
> > > If understand these new experimental APIs from above, then bit options is the best,
> > > and we didn't invent new words to describe them, just from the CPU & other *generic*
> > > technology. And the application can loop to check which kind of burst is running by
> > > just simple bit test.
> > >
> > > If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> > > like MLX5 supports ARM NEON, x86 SSE.
> > 
> > I have no word!
> > You really think other PMDs should learn from Intel how to "enhance" their PMD?
> > You talk about mlx5, did you look at its code? Did you see the burst modes
> > depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> > Or depending on which offloads are handled?
> > 
> > Again, the instruction set used by the function is a small part
> > of the burst mode optimization.
> > 
> > So you did not reply to my question:
> > Why not just returning a name for the selected Rx/Tx mode?
> 
> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> application to do further processing, strcmp, strstr ? Not so nice
> for C code, and it is not so standard, So switch it to bit definition.

Again, please answer my question: why do you need it?
I think it is just informative, that's why a string should be enough.
I am clearly against the bitmap because it is way too much restrictive.
I disagree that knowing it is using AVX2 or AVX512 is so interesting.
What you would like to know is whether it is processing packets 4 by 4,
for instance, or to know which offload is supported, or what hardware trick
is used in the datapath design.
There are so many options in a datapath design that it cannot be
represented with a bitmap. And it makes no sense to have some design
criterias more important than others.
I Cc an Intel architect (Edwin) who could explain you how much
a datapath design is more complicate than just using AVX instructions.

> If the API is not bad, but the data is not so good, then accept below ? ;-)

No, the API is bad.
Jerin Jacob Oct. 29, 2019, 3:37 a.m. UTC | #19 
> > > > struct rte_eth_burst_mode {
> > > >         uint64_t options;
> > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > };
> > >
> > > I really don't see how we can have generic flags.
> > > The flags which are proposed are just matching
> > > the functions implemented in Intel PMDs.
> > > And this is a complicate solution.
> > > Why not just returning a name for the selected Rx/Tx mode?
> >
> > +1 only for the name
> >
> > Let me clarify my earlier proposal:
> >
> > 1) The public ethdev API should return only "string" i.e the flags
> > SHOULD NOT be exposed as ethdev API
> > i.e
> > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> >
> > 2) The PMD interface  to the common code can be following
> >
> >  struct eth_pmd_burst_mode {
> >         uint64_t options;
> >          char name[128]; /* PMD specific burst mode information */
> > };
> >
> > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> >         uint16_t queue_id, struct eth_burst_mode *mode)
> >
> > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > flag to string converion(again internal to common code implemetation)
> > and concatenate with eth_pmd_burst_mode::name
> >
> > This would help to reuse some of the flags to name conversion logic
> > across all PMDs.
> > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > that case final
> > string only be eth_pmd_burst_mode::name.
> >
>
> In fact, 'rte_eth_burst_mode_option_name' for single option, not
> for struct eth_pmd_burst_mode::option[s]. Need loop to display them.

I see two issues with the flag approach in public API(Internally for
common code it fine to avoid code duplication)

1) We can not standardize all flags when it comes to HW specific
details. We should NOT pollute public API with HW specific details.
2) There is a danger if application starts taking any action based on
flags. It should be only for display purpose so in that case public
API should be the string to avoid misuse of the API(eventually the app
will fail on some PMD
if it takes any action based on the flag)
Wang, Haiyue Oct. 29, 2019, 4:44 a.m. UTC | #20 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 11:38
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> > > > > struct rte_eth_burst_mode {
> > > > >         uint64_t options;
> > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > };
> > > >
> > > > I really don't see how we can have generic flags.
> > > > The flags which are proposed are just matching
> > > > the functions implemented in Intel PMDs.
> > > > And this is a complicate solution.
> > > > Why not just returning a name for the selected Rx/Tx mode?
> > >
> > > +1 only for the name
> > >
> > > Let me clarify my earlier proposal:
> > >
> > > 1) The public ethdev API should return only "string" i.e the flags
> > > SHOULD NOT be exposed as ethdev API
> > > i.e
> > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > >
> > > 2) The PMD interface  to the common code can be following
> > >
> > >  struct eth_pmd_burst_mode {
> > >         uint64_t options;
> > >          char name[128]; /* PMD specific burst mode information */
> > > };
> > >
> > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > >
> > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > flag to string converion(again internal to common code implemetation)
> > > and concatenate with eth_pmd_burst_mode::name
> > >
> > > This would help to reuse some of the flags to name conversion logic
> > > across all PMDs.
> > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > that case final
> > > string only be eth_pmd_burst_mode::name.
> > >
> >
> > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> 
> I see two issues with the flag approach in public API(Internally for
> common code it fine to avoid code duplication)
> 
> 1) We can not standardize all flags when it comes to HW specific
> details. We should NOT pollute public API with HW specific details.

Currently, no detail to HW NIC specific.

> 2) There is a danger if application starts taking any action based on
> flags. It should be only for display purpose so in that case public
> API should be the string to avoid misuse of the API(eventually the app
> will fail on some PMD
> if it takes any action based on the flag)

These flags are *read only* for information. Can't image how to hack DPDK. ;-)
Jerin Jacob Oct. 29, 2019, 5:19 a.m. UTC | #21 
On Tue, Oct 29, 2019 at 10:14 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 29, 2019 11:38
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >
> > > > > > struct rte_eth_burst_mode {
> > > > > >         uint64_t options;
> > > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > > };
> > > > >
> > > > > I really don't see how we can have generic flags.
> > > > > The flags which are proposed are just matching
> > > > > the functions implemented in Intel PMDs.
> > > > > And this is a complicate solution.
> > > > > Why not just returning a name for the selected Rx/Tx mode?
> > > >
> > > > +1 only for the name
> > > >
> > > > Let me clarify my earlier proposal:
> > > >
> > > > 1) The public ethdev API should return only "string" i.e the flags
> > > > SHOULD NOT be exposed as ethdev API
> > > > i.e
> > > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > > >
> > > > 2) The PMD interface  to the common code can be following
> > > >
> > > >  struct eth_pmd_burst_mode {
> > > >         uint64_t options;
> > > >          char name[128]; /* PMD specific burst mode information */
> > > > };
> > > >
> > > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > > >
> > > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > > flag to string converion(again internal to common code implemetation)
> > > > and concatenate with eth_pmd_burst_mode::name
> > > >
> > > > This would help to reuse some of the flags to name conversion logic
> > > > across all PMDs.
> > > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > > that case final
> > > > string only be eth_pmd_burst_mode::name.
> > > >
> > >
> > > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> >
> > I see two issues with the flag approach in public API(Internally for
> > common code it fine to avoid code duplication)
> >
> > 1) We can not standardize all flags when it comes to HW specific
> > details. We should NOT pollute public API with HW specific details.
>
> Currently, no detail to HW NIC specific.

Yes. What if I want to add a "String" they represent a specific mode of PMD,
so that I know what mode PMD really runs.
It is not worth adding a flag for that in public API for HW specific notion.
That's the problem.

>
> > 2) There is a danger if application starts taking any action based on
> > flags. It should be only for display purpose so in that case public
> > API should be the string to avoid misuse of the API(eventually the app
> > will fail on some PMD
> > if it takes any action based on the flag)
>
> These flags are *read only* for information. Can't image how to hack DPDK. ;-)

To clarify:
If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
some action based on
if (flag == RTE_ETH_BURST_SIMPLE)
    do_some_thing();

If the purpose is ONLY for "display" as info then exposing as the string will
enable to NOT standardize i.e application can never check based on
the string name(as it is not standardized) hence no danger.

So what is the purpose of this API? Just display or are you expecting
the application can do any action based on this?
Wang, Haiyue Oct. 29, 2019, 5:42 a.m. UTC | #22 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 13:20
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 10:14 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 11:38
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > > > > > struct rte_eth_burst_mode {
> > > > > > >         uint64_t options;
> > > > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > > > };
> > > > > >
> > > > > > I really don't see how we can have generic flags.
> > > > > > The flags which are proposed are just matching
> > > > > > the functions implemented in Intel PMDs.
> > > > > > And this is a complicate solution.
> > > > > > Why not just returning a name for the selected Rx/Tx mode?
> > > > >
> > > > > +1 only for the name
> > > > >
> > > > > Let me clarify my earlier proposal:
> > > > >
> > > > > 1) The public ethdev API should return only "string" i.e the flags
> > > > > SHOULD NOT be exposed as ethdev API
> > > > > i.e
> > > > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > > > >
> > > > > 2) The PMD interface  to the common code can be following
> > > > >
> > > > >  struct eth_pmd_burst_mode {
> > > > >         uint64_t options;
> > > > >          char name[128]; /* PMD specific burst mode information */
> > > > > };
> > > > >
> > > > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > > > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > > > >
> > > > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > > > flag to string converion(again internal to common code implemetation)
> > > > > and concatenate with eth_pmd_burst_mode::name
> > > > >
> > > > > This would help to reuse some of the flags to name conversion logic
> > > > > across all PMDs.
> > > > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > > > that case final
> > > > > string only be eth_pmd_burst_mode::name.
> > > > >
> > > >
> > > > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > > > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> > >
> > > I see two issues with the flag approach in public API(Internally for
> > > common code it fine to avoid code duplication)
> > >
> > > 1) We can not standardize all flags when it comes to HW specific
> > > details. We should NOT pollute public API with HW specific details.
> >
> > Currently, no detail to HW NIC specific.
> 
> Yes. What if I want to add a "String" they represent a specific mode of PMD,
> so that I know what mode PMD really runs.
> It is not worth adding a flag for that in public API for HW specific notion.
> That's the problem.
> 
> >
> > > 2) There is a danger if application starts taking any action based on
> > > flags. It should be only for display purpose so in that case public
> > > API should be the string to avoid misuse of the API(eventually the app
> > > will fail on some PMD
> > > if it takes any action based on the flag)
> >
> > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> 
> To clarify:
> If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> some action based on
> if (flag == RTE_ETH_BURST_SIMPLE)
>     do_some_thing();
> 
> If the purpose is ONLY for "display" as info then exposing as the string will
> enable to NOT standardize i.e application can never check based on
> the string name(as it is not standardized) hence no danger.
> 
> So what is the purpose of this API? Just display or are you expecting
> the application can do any action based on this?

Oh, I see. Mainly for showing which burst rx/tx module running:

https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html

s = format (s, "%Utx burst function: %s\n",
  579                   format_white_space, indent + 2,
  580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
  581       s = format (s, "%Urx burst function: %s\n",
  582                   format_white_space, indent + 2,
  583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));

https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html

488 static const char *
  489 ptr2sname (void *p)
  490 {
  491   Dl_info info = { 0 };
  492 
  493   if (dladdr (p, &info) == 0)
  494     return 0;
  495 
  496   return info.dli_sname;
  497 }

    tx burst function: ixgbe_xmit_pkts
    rx burst function: ixgbe_recv_pkts

If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Jerin Jacob Oct. 29, 2019, 5:47 a.m. UTC | #23 
On Tue, Oct 29, 2019 at 11:12 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 29, 2019 13:20
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >
> > On Tue, Oct 29, 2019 at 10:14 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Tuesday, October 29, 2019 11:38
> > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> > Hemminger
> > > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > > <jerinj@marvell.com>
> > > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > > >
> > > > > > > > struct rte_eth_burst_mode {
> > > > > > > >         uint64_t options;
> > > > > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > > > > };
> > > > > > >
> > > > > > > I really don't see how we can have generic flags.
> > > > > > > The flags which are proposed are just matching
> > > > > > > the functions implemented in Intel PMDs.
> > > > > > > And this is a complicate solution.
> > > > > > > Why not just returning a name for the selected Rx/Tx mode?
> > > > > >
> > > > > > +1 only for the name
> > > > > >
> > > > > > Let me clarify my earlier proposal:
> > > > > >
> > > > > > 1) The public ethdev API should return only "string" i.e the flags
> > > > > > SHOULD NOT be exposed as ethdev API
> > > > > > i.e
> > > > > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > > > > >
> > > > > > 2) The PMD interface  to the common code can be following
> > > > > >
> > > > > >  struct eth_pmd_burst_mode {
> > > > > >         uint64_t options;
> > > > > >          char name[128]; /* PMD specific burst mode information */
> > > > > > };
> > > > > >
> > > > > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > > > > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > > > > >
> > > > > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > > > > flag to string converion(again internal to common code implemetation)
> > > > > > and concatenate with eth_pmd_burst_mode::name
> > > > > >
> > > > > > This would help to reuse some of the flags to name conversion logic
> > > > > > across all PMDs.
> > > > > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > > > > that case final
> > > > > > string only be eth_pmd_burst_mode::name.
> > > > > >
> > > > >
> > > > > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > > > > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> > > >
> > > > I see two issues with the flag approach in public API(Internally for
> > > > common code it fine to avoid code duplication)
> > > >
> > > > 1) We can not standardize all flags when it comes to HW specific
> > > > details. We should NOT pollute public API with HW specific details.
> > >
> > > Currently, no detail to HW NIC specific.
> >
> > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > so that I know what mode PMD really runs.
> > It is not worth adding a flag for that in public API for HW specific notion.
> > That's the problem.
> >
> > >
> > > > 2) There is a danger if application starts taking any action based on
> > > > flags. It should be only for display purpose so in that case public
> > > > API should be the string to avoid misuse of the API(eventually the app
> > > > will fail on some PMD
> > > > if it takes any action based on the flag)
> > >
> > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> >
> > To clarify:
> > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > some action based on
> > if (flag == RTE_ETH_BURST_SIMPLE)
> >     do_some_thing();
> >
> > If the purpose is ONLY for "display" as info then exposing as the string will
> > enable to NOT standardize i.e application can never check based on
> > the string name(as it is not standardized) hence no danger.
> >
> > So what is the purpose of this API? Just display or are you expecting
> > the application can do any action based on this?
>
> Oh, I see. Mainly for showing which burst rx/tx module running:

If so, the public API should be as string to avoid any other interpreation of
flags in application.

And it makes application life easy too.


>
> https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
>
> s = format (s, "%Utx burst function: %s\n",
>   579                   format_white_space, indent + 2,
>   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
>   581       s = format (s, "%Urx burst function: %s\n",
>   582                   format_white_space, indent + 2,
>   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
>
> https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
>
> 488 static const char *
>   489 ptr2sname (void *p)
>   490 {
>   491   Dl_info info = { 0 };
>   492
>   493   if (dladdr (p, &info) == 0)
>   494     return 0;
>   495
>   496   return info.dli_sname;
>   497 }
>
>     tx burst function: ixgbe_xmit_pkts
>     rx burst function: ixgbe_recv_pkts
>
> If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Wang, Haiyue Oct. 29, 2019, 5:56 a.m. UTC | #24 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 13:47
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 11:12 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 13:20
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > On Tue, Oct 29, 2019 at 10:14 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Tuesday, October 29, 2019 11:38
> > > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> > > Hemminger
> > > > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > > > <jerinj@marvell.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > > > >
> > > > > > > > > struct rte_eth_burst_mode {
> > > > > > > > >         uint64_t options;
> > > > > > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > > > > > };
> > > > > > > >
> > > > > > > > I really don't see how we can have generic flags.
> > > > > > > > The flags which are proposed are just matching
> > > > > > > > the functions implemented in Intel PMDs.
> > > > > > > > And this is a complicate solution.
> > > > > > > > Why not just returning a name for the selected Rx/Tx mode?
> > > > > > >
> > > > > > > +1 only for the name
> > > > > > >
> > > > > > > Let me clarify my earlier proposal:
> > > > > > >
> > > > > > > 1) The public ethdev API should return only "string" i.e the flags
> > > > > > > SHOULD NOT be exposed as ethdev API
> > > > > > > i.e
> > > > > > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > > > > > >
> > > > > > > 2) The PMD interface  to the common code can be following
> > > > > > >
> > > > > > >  struct eth_pmd_burst_mode {
> > > > > > >         uint64_t options;
> > > > > > >          char name[128]; /* PMD specific burst mode information */
> > > > > > > };
> > > > > > >
> > > > > > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > > > > > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > > > > > >
> > > > > > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > > > > > flag to string converion(again internal to common code implemetation)
> > > > > > > and concatenate with eth_pmd_burst_mode::name
> > > > > > >
> > > > > > > This would help to reuse some of the flags to name conversion logic
> > > > > > > across all PMDs.
> > > > > > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > > > > > that case final
> > > > > > > string only be eth_pmd_burst_mode::name.
> > > > > > >
> > > > > >
> > > > > > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > > > > > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> > > > >
> > > > > I see two issues with the flag approach in public API(Internally for
> > > > > common code it fine to avoid code duplication)
> > > > >
> > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > details. We should NOT pollute public API with HW specific details.
> > > >
> > > > Currently, no detail to HW NIC specific.
> > >
> > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > so that I know what mode PMD really runs.
> > > It is not worth adding a flag for that in public API for HW specific notion.
> > > That's the problem.
> > >
> > > >
> > > > > 2) There is a danger if application starts taking any action based on
> > > > > flags. It should be only for display purpose so in that case public
> > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > will fail on some PMD
> > > > > if it takes any action based on the flag)
> > > >
> > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > >
> > > To clarify:
> > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > some action based on
> > > if (flag == RTE_ETH_BURST_SIMPLE)
> > >     do_some_thing();
> > >
> > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > enable to NOT standardize i.e application can never check based on
> > > the string name(as it is not standardized) hence no danger.
> > >
> > > So what is the purpose of this API? Just display or are you expecting
> > > the application can do any action based on this?
> >
> > Oh, I see. Mainly for showing which burst rx/tx module running:
> 
> If so, the public API should be as string to avoid any other interpreation of
> flags in application.
> 
> And it makes application life easy too.
> 

No one is easy. ;-) Requirement is endless.

> 
> >
> > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> >
> > s = format (s, "%Utx burst function: %s\n",
> >   579                   format_white_space, indent + 2,
> >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> >   581       s = format (s, "%Urx burst function: %s\n",
> >   582                   format_white_space, indent + 2,
> >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> >
> > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> >
> > 488 static const char *
> >   489 ptr2sname (void *p)
> >   490 {
> >   491   Dl_info info = { 0 };
> >   492
> >   493   if (dladdr (p, &info) == 0)
> >   494     return 0;
> >   495
> >   496   return info.dli_sname;
> >   497 }
> >
> >     tx burst function: ixgbe_xmit_pkts
> >     rx burst function: ixgbe_recv_pkts
> >
> > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Wang, Haiyue Oct. 29, 2019, 6 a.m. UTC | #25 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 13:47
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 11:12 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 13:20
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > On Tue, Oct 29, 2019 at 10:14 AM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Tuesday, October 29, 2019 11:38
> > > > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> > > Hemminger
> > > > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > > > <jerinj@marvell.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > > > >
> > > > > > > > > struct rte_eth_burst_mode {
> > > > > > > > >         uint64_t options;
> > > > > > > > >         char dev_specific[128]; /* PMD has specific burst mode information */
> > > > > > > > > };
> > > > > > > >
> > > > > > > > I really don't see how we can have generic flags.
> > > > > > > > The flags which are proposed are just matching
> > > > > > > > the functions implemented in Intel PMDs.
> > > > > > > > And this is a complicate solution.
> > > > > > > > Why not just returning a name for the selected Rx/Tx mode?
> > > > > > >
> > > > > > > +1 only for the name
> > > > > > >
> > > > > > > Let me clarify my earlier proposal:
> > > > > > >
> > > > > > > 1) The public ethdev API should return only "string" i.e the flags
> > > > > > > SHOULD NOT be exposed as ethdev API
> > > > > > > i.e
> > > > > > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > > > > > >
> > > > > > > 2) The PMD interface  to the common code can be following
> > > > > > >
> > > > > > >  struct eth_pmd_burst_mode {
> > > > > > >         uint64_t options;
> > > > > > >          char name[128]; /* PMD specific burst mode information */
> > > > > > > };
> > > > > > >
> > > > > > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > > > > > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > > > > > >
> > > > > > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > > > > > flag to string converion(again internal to common code implemetation)
> > > > > > > and concatenate with eth_pmd_burst_mode::name
> > > > > > >
> > > > > > > This would help to reuse some of the flags to name conversion logic
> > > > > > > across all PMDs.
> > > > > > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > > > > > that case final
> > > > > > > string only be eth_pmd_burst_mode::name.
> > > > > > >
> > > > > >
> > > > > > In fact, 'rte_eth_burst_mode_option_name' for single option, not
> > > > > > for struct eth_pmd_burst_mode::option[s]. Need loop to display them.
> > > > >
> > > > > I see two issues with the flag approach in public API(Internally for
> > > > > common code it fine to avoid code duplication)
> > > > >
> > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > details. We should NOT pollute public API with HW specific details.
> > > >
> > > > Currently, no detail to HW NIC specific.
> > >
> > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > so that I know what mode PMD really runs.
> > > It is not worth adding a flag for that in public API for HW specific notion.
> > > That's the problem.
> > >
> > > >
> > > > > 2) There is a danger if application starts taking any action based on
> > > > > flags. It should be only for display purpose so in that case public
> > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > will fail on some PMD
> > > > > if it takes any action based on the flag)
> > > >
> > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > >
> > > To clarify:
> > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > some action based on
> > > if (flag == RTE_ETH_BURST_SIMPLE)
> > >     do_some_thing();
> > >
> > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > enable to NOT standardize i.e application can never check based on
> > > the string name(as it is not standardized) hence no danger.
> > >
> > > So what is the purpose of this API? Just display or are you expecting
> > > the application can do any action based on this?
> >
> > Oh, I see. Mainly for showing which burst rx/tx module running:
> 
> If so, the public API should be as string to avoid any other interpreation of
> flags in application.
> 
> And it makes application life easy too.
> 
> 

At first, we do use string, but string contains same words. Off course, this
is from CPU's view. Our two PMDs string are nearly the same, so we use bit
instead. And people may check which CPU's vertor using. And we provide to_string
to help make both happy. Not sure we really make them happy.

> >
> > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> >
> > s = format (s, "%Utx burst function: %s\n",
> >   579                   format_white_space, indent + 2,
> >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> >   581       s = format (s, "%Urx burst function: %s\n",
> >   582                   format_white_space, indent + 2,
> >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> >
> > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> >
> > 488 static const char *
> >   489 ptr2sname (void *p)
> >   490 {
> >   491   Dl_info info = { 0 };
> >   492
> >   493   if (dladdr (p, &info) == 0)
> >   494     return 0;
> >   495
> >   496   return info.dli_sname;
> >   497 }
> >
> >     tx burst function: ixgbe_xmit_pkts
> >     rx burst function: ixgbe_recv_pkts
> >
> > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Jerin Jacob Oct. 29, 2019, 8:34 a.m. UTC | #26 
> > > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > > details. We should NOT pollute public API with HW specific details.
> > > > >
> > > > > Currently, no detail to HW NIC specific.
> > > >
> > > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > > so that I know what mode PMD really runs.
> > > > It is not worth adding a flag for that in public API for HW specific notion.
> > > > That's the problem.
> > > >
> > > > >
> > > > > > 2) There is a danger if application starts taking any action based on
> > > > > > flags. It should be only for display purpose so in that case public
> > > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > > will fail on some PMD
> > > > > > if it takes any action based on the flag)
> > > > >
> > > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > > >
> > > > To clarify:
> > > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > > some action based on
> > > > if (flag == RTE_ETH_BURST_SIMPLE)
> > > >     do_some_thing();
> > > >
> > > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > > enable to NOT standardize i.e application can never check based on
> > > > the string name(as it is not standardized) hence no danger.
> > > >
> > > > So what is the purpose of this API? Just display or are you expecting
> > > > the application can do any action based on this?
> > >
> > > Oh, I see. Mainly for showing which burst rx/tx module running:
> >
> > If so, the public API should be as string to avoid any other interpreation of
> > flags in application.
> >
> > And it makes application life easy too.
> >
> >
>
> At first, we do use string, but string contains same words. Off course, this
> is from CPU's view. Our two PMDs string are nearly the same, so we use bit
> instead. And people may check which CPU's vertor using. And we provide to_string
> to help make both happy. Not sure we really make them happy.

# I understand the flags can enable us to reuse some of the code and I
agree with that.
But it has the downside mentioned above.

How about the following to have the best of both worlds.

1) The public ethdev API should return only "string" i.e the flags
SHOULD NOT be exposed as ethdev API
i.e
int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);

2) The PMD interface  to the common code can be following

 struct eth_pmd_burst_mode {
        uint64_t options;
         char name[128]; /* PMD specific burst mode information */
};

typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
        uint16_t queue_id, struct eth_burst_mode *mode)

3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
flag to string converion(again internal to common code implemetation)
and concatenate with eth_pmd_burst_mode::name

This would help to reuse some of the flags to name conversion logic
across all PMDs.
And PMD are free to return  eth_pmd_burst_mode::options as zero in
that case final
string only be eth_pmd_burst_mode::name.


>
> > >
> > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > >
> > > s = format (s, "%Utx burst function: %s\n",
> > >   579                   format_white_space, indent + 2,
> > >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> > >   581       s = format (s, "%Urx burst function: %s\n",
> > >   582                   format_white_space, indent + 2,
> > >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> > >
> > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > >
> > > 488 static const char *
> > >   489 ptr2sname (void *p)
> > >   490 {
> > >   491   Dl_info info = { 0 };
> > >   492
> > >   493   if (dladdr (p, &info) == 0)
> > >   494     return 0;
> > >   495
> > >   496   return info.dli_sname;
> > >   497 }
> > >
> > >     tx burst function: ixgbe_xmit_pkts
> > >     rx burst function: ixgbe_recv_pkts
> > >
> > > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Wang, Haiyue Oct. 29, 2019, 11:26 a.m. UTC | #27 
Hi Jerin,

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 16:35
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> > > > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > > > details. We should NOT pollute public API with HW specific details.
> > > > > >
> > > > > > Currently, no detail to HW NIC specific.
> > > > >
> > > > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > > > so that I know what mode PMD really runs.
> > > > > It is not worth adding a flag for that in public API for HW specific notion.
> > > > > That's the problem.
> > > > >
> > > > > >
> > > > > > > 2) There is a danger if application starts taking any action based on
> > > > > > > flags. It should be only for display purpose so in that case public
> > > > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > > > will fail on some PMD
> > > > > > > if it takes any action based on the flag)
> > > > > >
> > > > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > > > >
> > > > > To clarify:
> > > > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > > > some action based on
> > > > > if (flag == RTE_ETH_BURST_SIMPLE)
> > > > >     do_some_thing();
> > > > >
> > > > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > > > enable to NOT standardize i.e application can never check based on
> > > > > the string name(as it is not standardized) hence no danger.
> > > > >
> > > > > So what is the purpose of this API? Just display or are you expecting
> > > > > the application can do any action based on this?
> > > >
> > > > Oh, I see. Mainly for showing which burst rx/tx module running:
> > >
> > > If so, the public API should be as string to avoid any other interpreation of
> > > flags in application.
> > >
> > > And it makes application life easy too.
> > >
> > >
> >
> > At first, we do use string, but string contains same words. Off course, this
> > is from CPU's view. Our two PMDs string are nearly the same, so we use bit
> > instead. And people may check which CPU's vertor using. And we provide to_string
> > to help make both happy. Not sure we really make them happy.
> 
> # I understand the flags can enable us to reuse some of the code and I
> agree with that.
> But it has the downside mentioned above.
> 
> How about the following to have the best of both worlds.
> 
> 1) The public ethdev API should return only "string" i.e the flags
> SHOULD NOT be exposed as ethdev API
> i.e
> int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> 

How about *_str_* style ?

int
rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
			  	      char *buf, int buflen)


> 2) The PMD interface  to the common code can be following
> 
>  struct eth_pmd_burst_mode {
>         uint64_t options;
>          char name[128]; /* PMD specific burst mode information */
> };
> 

struct eth_pmd_burst_mode {
	uint64_t options;
	char dev_specific[128]; /* PMD specific burst mode information */
};

Still use 'dev_specific' ? Since whole structure 'struct eth_pmd_burst_mode'
will be translated into string name.

> typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
>         uint16_t queue_id, struct eth_burst_mode *mode)
> 
> 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> flag to string converion(again internal to common code implemetation)
> and concatenate with eth_pmd_burst_mode::name
> 

Should be better to use the user input buffer w/ size ? Since now 'option'
is private to PMD.

int
rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
			  	      char *buf, int buflen)

And the concatenate format : "options string, dev_specific"
                                            ^
                                            If option is non-zero, and has device specific, add this ','
                                            as separation ?

> This would help to reuse some of the flags to name conversion logic
> across all PMDs.
> And PMD are free to return  eth_pmd_burst_mode::options as zero in
> that case final
> string only be eth_pmd_burst_mode::name.
> 
> 
> >
> > > >
> > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > >
> > > > s = format (s, "%Utx burst function: %s\n",
> > > >   579                   format_white_space, indent + 2,
> > > >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> > > >   581       s = format (s, "%Urx burst function: %s\n",
> > > >   582                   format_white_space, indent + 2,
> > > >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> > > >
> > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > >
> > > > 488 static const char *
> > > >   489 ptr2sname (void *p)
> > > >   490 {
> > > >   491   Dl_info info = { 0 };
> > > >   492
> > > >   493   if (dladdr (p, &info) == 0)
> > > >   494     return 0;
> > > >   495
> > > >   496   return info.dli_sname;
> > > >   497 }
> > > >
> > > >     tx burst function: ixgbe_xmit_pkts
> > > >     rx burst function: ixgbe_recv_pkts
> > > >
> > > > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Jerin Jacob Oct. 29, 2019, 12:56 p.m. UTC | #28 
On Tue, Oct 29, 2019 at 4:56 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
>
> Hi Jerin,

Hi Wang

>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 29, 2019 16:35
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >
> > > > > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > > > > details. We should NOT pollute public API with HW specific details.
> > > > > > >
> > > > > > > Currently, no detail to HW NIC specific.
> > > > > >
> > > > > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > > > > so that I know what mode PMD really runs.
> > > > > > It is not worth adding a flag for that in public API for HW specific notion.
> > > > > > That's the problem.
> > > > > >
> > > > > > >
> > > > > > > > 2) There is a danger if application starts taking any action based on
> > > > > > > > flags. It should be only for display purpose so in that case public
> > > > > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > > > > will fail on some PMD
> > > > > > > > if it takes any action based on the flag)
> > > > > > >
> > > > > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > > > > >
> > > > > > To clarify:
> > > > > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > > > > some action based on
> > > > > > if (flag == RTE_ETH_BURST_SIMPLE)
> > > > > >     do_some_thing();
> > > > > >
> > > > > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > > > > enable to NOT standardize i.e application can never check based on
> > > > > > the string name(as it is not standardized) hence no danger.
> > > > > >
> > > > > > So what is the purpose of this API? Just display or are you expecting
> > > > > > the application can do any action based on this?
> > > > >
> > > > > Oh, I see. Mainly for showing which burst rx/tx module running:
> > > >
> > > > If so, the public API should be as string to avoid any other interpreation of
> > > > flags in application.
> > > >
> > > > And it makes application life easy too.
> > > >
> > > >
> > >
> > > At first, we do use string, but string contains same words. Off course, this
> > > is from CPU's view. Our two PMDs string are nearly the same, so we use bit
> > > instead. And people may check which CPU's vertor using. And we provide to_string
> > > to help make both happy. Not sure we really make them happy.
> >
> > # I understand the flags can enable us to reuse some of the code and I
> > agree with that.
> > But it has the downside mentioned above.
> >
> > How about the following to have the best of both worlds.
> >
> > 1) The public ethdev API should return only "string" i.e the flags
> > SHOULD NOT be exposed as ethdev API
> > i.e
> > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> >
>
> How about *_str_* style ?

_name kind of implies it the string. may be _mode is good as it is short.

> int
> rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
>                                       char *buf, int buflen)

We don't need buflen as it is not known to the application. The
typical pattern, we followed,
in dpdk is, when function called buf as NULL then the function returns
the expected size so that
the application can alloc and get the buffer from ethdev layer on the
next iteration.





>
>
> > 2) The PMD interface  to the common code can be following
> >
> >  struct eth_pmd_burst_mode {
> >         uint64_t options;
> >          char name[128]; /* PMD specific burst mode information */
> > };
> >
>
> struct eth_pmd_burst_mode {
>         uint64_t options;
>         char dev_specific[128]; /* PMD specific burst mode information */
> };
>
> Still use 'dev_specific' ? Since whole structure 'struct eth_pmd_burst_mode'
> will be translated into string name.

Yes.
options - for generic flags to reuse the code
dev_specific - for PMD specific string/name

>
> > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> >         uint16_t queue_id, struct eth_burst_mode *mode)
> >
> > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > flag to string converion(again internal to common code implemetation)
> > and concatenate with eth_pmd_burst_mode::name
> >
>
> Should be better to use the user input buffer w/ size ? Since now 'option'
> is private to PMD.

see above. No need for a separate argument. NULL case it can return
the expected size.

> int
> rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
>                                       char *buf, int buflen)
>
> And the concatenate format : "options string, dev_specific"
>                                             ^
>                                             If option is non-zero, and has device specific, add this ','
>                                             as separation ?

Looks good to me.

>
> > This would help to reuse some of the flags to name conversion logic
> > across all PMDs.
> > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > that case final
> > string only be eth_pmd_burst_mode::name.
> >
> >
> > >
> > > > >
> > > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > > >
> > > > > s = format (s, "%Utx burst function: %s\n",
> > > > >   579                   format_white_space, indent + 2,
> > > > >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> > > > >   581       s = format (s, "%Urx burst function: %s\n",
> > > > >   582                   format_white_space, indent + 2,
> > > > >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> > > > >
> > > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > > >
> > > > > 488 static const char *
> > > > >   489 ptr2sname (void *p)
> > > > >   490 {
> > > > >   491   Dl_info info = { 0 };
> > > > >   492
> > > > >   493   if (dladdr (p, &info) == 0)
> > > > >   494     return 0;
> > > > >   495
> > > > >   496   return info.dli_sname;
> > > > >   497 }
> > > > >
> > > > >     tx burst function: ixgbe_xmit_pkts
> > > > >     rx burst function: ixgbe_recv_pkts
> > > > >
> > > > > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Wang, Haiyue Oct. 29, 2019, 1:51 p.m. UTC | #29 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 20:57
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 4:56 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > Hi Jerin,
> 
> Hi Wang
> 
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 16:35
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > > > > > > > 1) We can not standardize all flags when it comes to HW specific
> > > > > > > > > details. We should NOT pollute public API with HW specific details.
> > > > > > > >
> > > > > > > > Currently, no detail to HW NIC specific.
> > > > > > >
> > > > > > > Yes. What if I want to add a "String" they represent a specific mode of PMD,
> > > > > > > so that I know what mode PMD really runs.
> > > > > > > It is not worth adding a flag for that in public API for HW specific notion.
> > > > > > > That's the problem.
> > > > > > >
> > > > > > > >
> > > > > > > > > 2) There is a danger if application starts taking any action based on
> > > > > > > > > flags. It should be only for display purpose so in that case public
> > > > > > > > > API should be the string to avoid misuse of the API(eventually the app
> > > > > > > > > will fail on some PMD
> > > > > > > > > if it takes any action based on the flag)
> > > > > > > >
> > > > > > > > These flags are *read only* for information. Can't image how to hack DPDK. ;-)
> > > > > > >
> > > > > > > To clarify:
> > > > > > > If we expose flag say RTE_ETH_BURST_SIMPLE then the application can take
> > > > > > > some action based on
> > > > > > > if (flag == RTE_ETH_BURST_SIMPLE)
> > > > > > >     do_some_thing();
> > > > > > >
> > > > > > > If the purpose is ONLY for "display" as info then exposing as the string will
> > > > > > > enable to NOT standardize i.e application can never check based on
> > > > > > > the string name(as it is not standardized) hence no danger.
> > > > > > >
> > > > > > > So what is the purpose of this API? Just display or are you expecting
> > > > > > > the application can do any action based on this?
> > > > > >
> > > > > > Oh, I see. Mainly for showing which burst rx/tx module running:
> > > > >
> > > > > If so, the public API should be as string to avoid any other interpreation of
> > > > > flags in application.
> > > > >
> > > > > And it makes application life easy too.
> > > > >
> > > > >
> > > >
> > > > At first, we do use string, but string contains same words. Off course, this
> > > > is from CPU's view. Our two PMDs string are nearly the same, so we use bit
> > > > instead. And people may check which CPU's vertor using. And we provide to_string
> > > > to help make both happy. Not sure we really make them happy.
> > >
> > > # I understand the flags can enable us to reuse some of the code and I
> > > agree with that.
> > > But it has the downside mentioned above.
> > >
> > > How about the following to have the best of both worlds.
> > >
> > > 1) The public ethdev API should return only "string" i.e the flags
> > > SHOULD NOT be exposed as ethdev API
> > > i.e
> > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > >
> >
> > How about *_str_* style ?
> 
> _name kind of implies it the string. may be _mode is good as it is short.
> 
> > int
> > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> >                                       char *buf, int buflen)
> 

About the function, keep the same is better ? Then we need no whole
replace, just update the parameters, and the parameters indicated that
it is in string format.

> We don't need buflen as it is not known to the application. The
> typical pattern, we followed,
> in dpdk is, when function called buf as NULL then the function returns
> the expected size so that
> the application can alloc and get the buffer from ethdev layer on the
> next iteration.
> 
> 

A little complicated and too heavy for using ? where is the example code ?
I found that 'snprintf' had this feature, but 'sprintf' didn't. And we need
to loop all the options, hard to do like: 'buf + len' for next string ?

int main(void)
{
        int len;
        char *buf = NULL;

        len = sprintf(buf, "test %d", 2);

        printf("len = %d\n", len);

        return 0;
}

Segmentation fault (core dumped)

==============

#include <stdio.h>


int main(void)
{
        int len;
        char *buf = NULL;

        len = snprintf(buf, 0, "test %d", 2);

        printf("len = %d\n", len);

        return 0;
}

len = 6

> 
> 
> 
> >
> >
> > > 2) The PMD interface  to the common code can be following
> > >
> > >  struct eth_pmd_burst_mode {
> > >         uint64_t options;
> > >          char name[128]; /* PMD specific burst mode information */
> > > };
> > >
> >
> > struct eth_pmd_burst_mode {
> >         uint64_t options;
> >         char dev_specific[128]; /* PMD specific burst mode information */
> > };
> >
> > Still use 'dev_specific' ? Since whole structure 'struct eth_pmd_burst_mode'
> > will be translated into string name.
> 
> Yes.
> options - for generic flags to reuse the code
> dev_specific - for PMD specific string/name
> 
> >
> > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > >
> > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > flag to string converion(again internal to common code implemetation)
> > > and concatenate with eth_pmd_burst_mode::name
> > >
> >
> > Should be better to use the user input buffer w/ size ? Since now 'option'
> > is private to PMD.
> 
> see above. No need for a separate argument. NULL case it can return
> the expected size.
> 
> > int
> > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> >                                       char *buf, int buflen)
> >
> > And the concatenate format : "options string, dev_specific"
> >                                             ^
> >                                             If option is non-zero, and has device specific, add this
> ','
> >                                             as separation ?
> 
> Looks good to me.
> 
> >
> > > This would help to reuse some of the flags to name conversion logic
> > > across all PMDs.
> > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > that case final
> > > string only be eth_pmd_burst_mode::name.
> > >
> > >
> > > >
> > > > > >
> > > > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > > > >
> > > > > > s = format (s, "%Utx burst function: %s\n",
> > > > > >   579                   format_white_space, indent + 2,
> > > > > >   580                   ptr2sname (rte_eth_devices[xd->port_id].tx_pkt_burst));
> > > > > >   581       s = format (s, "%Urx burst function: %s\n",
> > > > > >   582                   format_white_space, indent + 2,
> > > > > >   583                   ptr2sname (rte_eth_devices[xd->port_id].rx_pkt_burst));
> > > > > >
> > > > > > https://docs.fd.io/vpp/18.11/d7/d1d/plugins_2dpdk_2device_2format_8c_source.html
> > > > > >
> > > > > > 488 static const char *
> > > > > >   489 ptr2sname (void *p)
> > > > > >   490 {
> > > > > >   491   Dl_info info = { 0 };
> > > > > >   492
> > > > > >   493   if (dladdr (p, &info) == 0)
> > > > > >   494     return 0;
> > > > > >   495
> > > > > >   496   return info.dli_sname;
> > > > > >   497 }
> > > > > >
> > > > > >     tx burst function: ixgbe_xmit_pkts
> > > > > >     rx burst function: ixgbe_recv_pkts
> > > > > >
> > > > > > If the PMD's rx/tx is *static* function, 'ptr2name' returns 'nil'.
Jerin Jacob Oct. 29, 2019, 2:08 p.m. UTC | #30 
> > > >
> > >
> > > How about *_str_* style ?
> >
> > _name kind of implies it the string. may be _mode is good as it is short.
> >
> > > int
> > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > >                                       char *buf, int buflen)
> >
>
> About the function, keep the same is better ? Then we need no whole
> replace, just update the parameters, and the parameters indicated that
> it is in string format.

In this case, we need additional PMD op to get the buflen as
the application will not know the buffer size in advance. It needs to come
from the driver and common code.


See below.

>
> > We don't need buflen as it is not known to the application. The
> > typical pattern, we followed,
> > in dpdk is, when function called buf as NULL then the function returns
> > the expected size so that
> > the application can alloc and get the buffer from ethdev layer on the
> > next iteration.
> >
> >
>
> A little complicated and too heavy for using ? where is the example code ?

See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
and similar use case in DPDK.
Ferruh Yigit Oct. 29, 2019, 2:27 p.m. UTC | #31 
On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> 26/10/2019 11:23, Wang, Haiyue:
>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>> 26/10/2019 06:40, Wang, Haiyue:
>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>> like AVX2.
>>>>>>>>>
>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>
>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>
>>>>>>> I'm not saying blocking the merge.
>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>> in this case. Same for Andrew I guess.
>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>
>>>>>>>>>> +/**
>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>> + */
>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>> +  uint64_t options;
>>>>>>>>>> +};
>>>>>>>>>
>>>>>>>>> Why a struct for an integer?
>>>>>>>>
>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>> thing in the future.
>>>>>>>
>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>
>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>> and when a pass to the application, let common code make final string as
>>>>>> (options flags to string + dev_specific)
>>>>>>
>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>> interested in such a scheme.
>>>>>> Generic flags will help at least to have some common code.
>>>>>>
>>>>>> [1]
>>>>>> struct rte_eth_burst_mode {
>>>>>>         uint64_t options;
>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>> };
>>>>>
>>>>> I really don't see how we can have generic flags.
>>>>> The flags which are proposed are just matching
>>>>> the functions implemented in Intel PMDs.
>>>>> And this is a complicate solution.
>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>
>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>> variety of CPU architectures."
>>>
>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>> They just match some features of the Intel PMDs.
>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>> You totally missed the point of generic burst mode description.
>>>
>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>> technology. And the application can loop to check which kind of burst is running by
>>>> just simple bit test.
>>>>
>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>
>>> I have no word!
>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>> Or depending on which offloads are handled?
>>>
>>> Again, the instruction set used by the function is a small part
>>> of the burst mode optimization.
>>>
>>> So you did not reply to my question:
>>> Why not just returning a name for the selected Rx/Tx mode?
>>
>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>> application to do further processing, strcmp, strstr ? Not so nice
>> for C code, and it is not so standard, So switch it to bit definition.
> 
> Again, please answer my question: why do you need it?
> I think it is just informative, that's why a string should be enough.
> I am clearly against the bitmap because it is way too much restrictive.
> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> What you would like to know is whether it is processing packets 4 by 4,
> for instance, or to know which offload is supported, or what hardware trick
> is used in the datapath design.
> There are so many options in a datapath design that it cannot be
> represented with a bitmap. And it makes no sense to have some design
> criterias more important than others.
> I Cc an Intel architect (Edwin) who could explain you how much
> a datapath design is more complicate than just using AVX instructions.

As I understand this is to let applications to give informed decision based on
what vectorization is used in the driver, currently this is not know by the
application.

And as previously replied, the main target of the API is to define the vector
path, not all optimizations, so the number is limited.
There are many optimization in the data path, I agree we may not represent all
of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
causing this confusion, perhaps we can remove them.

And if the requirement from the application is just informative, I would agree
that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
is the main API to provide the information and
'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
this information.
Wang, Haiyue Oct. 29, 2019, 3:42 p.m. UTC | #32 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 22:09
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> > > > >
> > > >
> > > > How about *_str_* style ?
> > >
> > > _name kind of implies it the string. may be _mode is good as it is short.
> > >
> > > > int
> > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > >                                       char *buf, int buflen)
> > >
> >
> > About the function, keep the same is better ? Then we need no whole
> > replace, just update the parameters, and the parameters indicated that
> > it is in string format.
> 
> In this case, we need additional PMD op to get the buflen as
> the application will not know the buffer size in advance. It needs to come
> from the driver and common code.
> 
> 
> See below.
> 
> >
> > > We don't need buflen as it is not known to the application. The
> > > typical pattern, we followed,
> > > in dpdk is, when function called buf as NULL then the function returns
> > > the expected size so that
> > > the application can alloc and get the buffer from ethdev layer on the
> > > next iteration.
> > >
> > >
> >
> > A little complicated and too heavy for using ? where is the example code ?
> 
> See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> and similar use case in DPDK.

In fact, this is no so complex as dynamic string handling. :)

	/* Get count */
	cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
	if (cnt_xstats  < 0) {
		printf("Error: Cannot get count of xstats\n");
		return;
	}

xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);

struct rte_eth_xstat_name {
	char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
};


Frankly speaking, after re-thinking, I prefer to keep current design.
1) Use the structure to expose the *raw* data. Make the APIs work as
a SDK, DON'T image to format the string for user. User can call the
API to dump to file, print to console etc. Because he has the raw
data.

struct rte_eth_burst_mode {
	uint64_t options;
};

The 'options' bit definition reflects the rx/tx source code structure roughly:

"tree drivers/net/ | grep rxtx"

│   ├── i40e_rxtx.c
│   ├── i40e_rxtx.h
│   ├── i40e_rxtx_vec_altivec.c
│   ├── i40e_rxtx_vec_avx2.c
│   ├── i40e_rxtx_vec_common.h
│   ├── i40e_rxtx_vec_neon.c
│   ├── i40e_rxtx_vec_sse.c
│   ├── iavf_rxtx.c
│   ├── iavf_rxtx.h
│   ├── iavf_rxtx_vec_avx2.c
│   ├── iavf_rxtx_vec_common.h
│   ├── iavf_rxtx_vec_sse.c
│   ├── ice_rxtx.c
│   ├── ice_rxtx.h
│   ├── ice_rxtx_vec_avx2.c
│   ├── ice_rxtx_vec_common.h
│   ├── ice_rxtx_vec_sse.c
│   ├── ixgbe_rxtx.c
│   ├── ixgbe_rxtx.h
│   ├── ixgbe_rxtx_vec_common.h
│   ├── ixgbe_rxtx_vec_neon.c
│   ├── ixgbe_rxtx_vec_sse.c
│   ├── lio_rxtx.c
│   ├── lio_rxtx.h
│   ├── mlx4_rxtx.c
│   ├── mlx4_rxtx.h
│   ├── mlx5_rxtx.c
│   ├── mlx5_rxtx.h
│   ├── mlx5_rxtx_vec_altivec.h
│   ├── mlx5_rxtx_vec.c
│   ├── mlx5_rxtx_vec.h
│   ├── mlx5_rxtx_vec_neon.h
│   ├── mlx5_rxtx_vec_sse.h
│   ├── mvneta_rxtx.c
│   ├── mvneta_rxtx.h
│   ├── hn_rxtx.c
│   ├── octeontx_rxtx.c
│   ├── octeontx_rxtx.h
│   ├── qede_rxtx.c
│   ├── qede_rxtx.h
│   ├── nicvf_rxtx.c
│   ├── nicvf_rxtx.h
│   ├── virtio_rxtx.c
│   ├── virtio_rxtx.h
│   ├── virtio_rxtx_simple_altivec.c
│   ├── virtio_rxtx_simple.c
│   ├── virtio_rxtx_simple.h
│   ├── virtio_rxtx_simple_neon.c
│   ├── virtio_rxtx_simple_sse.c
    └── vmxnet3_rxtx.c

2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
   enhance the APIs step by step, and do it as needed.
Jerin Jacob Oct. 29, 2019, 3:59 p.m. UTC | #33 
On Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Tuesday, October 29, 2019 22:09
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > <jerinj@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >
> > > > > >
> > > > >
> > > > > How about *_str_* style ?
> > > >
> > > > _name kind of implies it the string. may be _mode is good as it is short.
> > > >
> > > > > int
> > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > > >                                       char *buf, int buflen)
> > > >
> > >
> > > About the function, keep the same is better ? Then we need no whole
> > > replace, just update the parameters, and the parameters indicated that
> > > it is in string format.
> >
> > In this case, we need additional PMD op to get the buflen as
> > the application will not know the buffer size in advance. It needs to come
> > from the driver and common code.
> >
> >
> > See below.
> >
> > >
> > > > We don't need buflen as it is not known to the application. The
> > > > typical pattern, we followed,
> > > > in dpdk is, when function called buf as NULL then the function returns
> > > > the expected size so that
> > > > the application can alloc and get the buffer from ethdev layer on the
> > > > next iteration.
> > > >
> > > >
> > >
> > > A little complicated and too heavy for using ? where is the example code ?
> >
> > See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> > and similar use case in DPDK.
>
> In fact, this is no so complex as dynamic string handling. :)
>
>         /* Get count */
>         cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
>         if (cnt_xstats  < 0) {
>                 printf("Error: Cannot get count of xstats\n");
>                 return;
>         }
>
> xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);
>
> struct rte_eth_xstat_name {
>         char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
> };


not really, it will be,[1]

count = rte_eth_rx_burst_mode_name(port_id, queue_id, NULL);
buf = malloc(count);
count = rte_eth_rx_burst_mode_name(port_id, queue_id, buf);


>
>
> Frankly speaking, after re-thinking, I prefer to keep current design.
> 1) Use the structure to expose the *raw* data. Make the APIs work as
> a SDK, DON'T image to format the string for user. User can call the
> API to dump to file, print to console etc. Because he has the raw
> data.

[1] Dont have such issue.

>
> struct rte_eth_burst_mode {
>         uint64_t options;
> };
>
> The 'options' bit definition reflects the rx/tx source code structure roughly:
>
> "tree drivers/net/ | grep rxtx"
> │   ├── virtio_rxtx_simple_sse.c
>     └── vmxnet3_rxtx.c

Files don't represent the actual mode PMD is running. So listing the
file example is not correct.


>
> 2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
>    enhance the APIs step by step, and do it as needed.

This would change ABI for no reason and who allocates the memory for
dev_specific?
Wang, Haiyue Oct. 29, 2019, 4:16 p.m. UTC | #34 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 23:59
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 22:09
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > > > > >
> > > > > >
> > > > > > How about *_str_* style ?
> > > > >
> > > > > _name kind of implies it the string. may be _mode is good as it is short.
> > > > >
> > > > > > int
> > > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > > > >                                       char *buf, int buflen)
> > > > >
> > > >
> > > > About the function, keep the same is better ? Then we need no whole
> > > > replace, just update the parameters, and the parameters indicated that
> > > > it is in string format.
> > >
> > > In this case, we need additional PMD op to get the buflen as
> > > the application will not know the buffer size in advance. It needs to come
> > > from the driver and common code.
> > >
> > >
> > > See below.
> > >
> > > >
> > > > > We don't need buflen as it is not known to the application. The
> > > > > typical pattern, we followed,
> > > > > in dpdk is, when function called buf as NULL then the function returns
> > > > > the expected size so that
> > > > > the application can alloc and get the buffer from ethdev layer on the
> > > > > next iteration.
> > > > >
> > > > >
> > > >
> > > > A little complicated and too heavy for using ? where is the example code ?
> > >
> > > See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> > > and similar use case in DPDK.
> >
> > In fact, this is no so complex as dynamic string handling. :)
> >
> >         /* Get count */
> >         cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
> >         if (cnt_xstats  < 0) {
> >                 printf("Error: Cannot get count of xstats\n");
> >                 return;
> >         }
> >
> > xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);
> >
> > struct rte_eth_xstat_name {
> >         char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
> > };
> 
> 
> not really, it will be,[1]
> 
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, NULL);
> buf = malloc(count);
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, buf);
> 
> 

I mean 'cnt_xstats' can be calculated like:
	count = RTE_NB_STATS;
	count += nb_rxqs * RTE_NB_RXQ_STATS;
	count += nb_txqs * RTE_NB_TXQ_STATS;

But for string, what I know is that use 'snprintf(NULL, 0, ...)' to get
the real length, in other words:
	1). NULL, call 'snprintf' to loop to get the length
	2). Not none, call 'sprint' to loop to dump into buffer.
 So in the function, have to handle two kind of loops.

And application has to handle memory allocation, free etc. Why not
just use a structure ? It is clean.

> >
> >
> > Frankly speaking, after re-thinking, I prefer to keep current design.
> > 1) Use the structure to expose the *raw* data. Make the APIs work as
> > a SDK, DON'T image to format the string for user. User can call the
> > API to dump to file, print to console etc. Because he has the raw
> > data.
> 
> [1] Dont have such issue.
> 
> >
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> > };
> >
> > The 'options' bit definition reflects the rx/tx source code structure roughly:
> >
> > "tree drivers/net/ | grep rxtx"
> > │   ├── virtio_rxtx_simple_sse.c
> >     └── vmxnet3_rxtx.c
> 
> Files don't represent the actual mode PMD is running. So listing the
> file example is not correct.
> 

I mean the function in it.

> 
> >
> > 2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
> >    enhance the APIs step by step, and do it as needed.
> 
> This would change ABI for no reason and who allocates the memory for
> dev_specific?

I mean like 'char dev_specific[128]', not zero length data. Sorry for confusion.
Ferruh Yigit Oct. 29, 2019, 4:59 p.m. UTC | #35 
On 10/26/2019 7:58 AM, Jerin Jacob wrote:
> On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> 25/10/2019 18:02, Jerin Jacob:
>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>> that allows an application to retrieve the mode information about
>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>> like AVX2.
>>>>>>
>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>
>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>
>>>> I'm not saying blocking the merge.
>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>> in this case. Same for Andrew I guess.
>>>> Note: it is merged in master and I am looking to improve this feature.
>>>
>>>>>>> +/**
>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>> + */
>>>>>>> +struct rte_eth_burst_mode {
>>>>>>> +  uint64_t options;
>>>>>>> +};
>>>>>>
>>>>>> Why a struct for an integer?
>>>>>
>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>> thing in the future.
>>>>
>>>> I would replace it with a string. This is the most flexible API.
>>>
>>> IMO, Probably, best of both worlds make a good option here,
>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>> and when a pass to the application, let common code make final string as
>>> (options flags to string + dev_specific)
>>>
>>> options flag can be zero if PMD does not have any generic flags nor
>>> interested in such a scheme.
>>> Generic flags will help at least to have some common code.
>>>
>>> [1]
>>> struct rte_eth_burst_mode {
>>>         uint64_t options;
>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>> };
>>
>> I really don't see how we can have generic flags.
>> The flags which are proposed are just matching
>> the functions implemented in Intel PMDs.
>> And this is a complicate solution.
>> Why not just returning a name for the selected Rx/Tx mode?
> 
> +1 only for the name
> 
> Let me clarify my earlier proposal:
> 
> 1) The public ethdev API should return only "string" i.e the flags
> SHOULD NOT be exposed as ethdev API
> i.e
> int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> 
> 2) The PMD interface  to the common code can be following
> 
>  struct eth_pmd_burst_mode {
>         uint64_t options;
>          char name[128]; /* PMD specific burst mode information */
> };
> 
> typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
>         uint16_t queue_id, struct eth_burst_mode *mode)
> 
> 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> flag to string converion(again internal to common code implemetation)
> and concatenate with eth_pmd_burst_mode::name
> 
> This would help to reuse some of the flags to name conversion logic
> across all PMDs.
> And PMD are free to return  eth_pmd_burst_mode::options as zero in
> that case final
> string only be eth_pmd_burst_mode::name.
> 
> I don't see any downside with this approach and it best of both worlds.
> 

I agree it will be hard or restrictive if we want to represent the all data path
options with standardized data.

But the free text string is good for logging, but not good if the application
will get this input and give some decision with it.

To combine both two, what do you think a mixed approach, similar to what Jerin
described but both options and string is visible to application,
and make 'options' only for vectorization information which is limited and be
standardized:

int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
	struct rte_eth_burst_mode *mode);

struct rte_eth_burst_mode {
	uint64_t options; // This is only for VECTORIZATION mode
	char *alternate_options;
}

since "burst_mode:options" only for vectorization, it is limited and can be easy
to consume by applications.
This means removing some data path options, like "BULK_ALLOC" from current struct.

'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
parameter and convert the 'options' to string and combine into single string as
a helper function to the applications.

And +1 to providing NULL "alternate_options" can return the size of that string.

And as we find more common/standard data path options, we can move them to the
bitfield and remove from the free text. Does it make sense?
Jerin Jacob Oct. 30, 2019, 4:38 a.m. UTC | #36 
On Tue, Oct 29, 2019 at 10:29 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 10/26/2019 7:58 AM, Jerin Jacob wrote:
> > On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>
> >> 25/10/2019 18:02, Jerin Jacob:
> >>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>> that allows an application to retrieve the mode information about
> >>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>> like AVX2.
> >>>>>>
> >>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>
> >>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>
> >>>> I'm not saying blocking the merge.
> >>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>> in this case. Same for Andrew I guess.
> >>>> Note: it is merged in master and I am looking to improve this feature.
> >>>
> >>>>>>> +/**
> >>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>> + */
> >>>>>>> +struct rte_eth_burst_mode {
> >>>>>>> +  uint64_t options;
> >>>>>>> +};
> >>>>>>
> >>>>>> Why a struct for an integer?
> >>>>>
> >>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>> thing in the future.
> >>>>
> >>>> I would replace it with a string. This is the most flexible API.
> >>>
> >>> IMO, Probably, best of both worlds make a good option here,
> >>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>> and when a pass to the application, let common code make final string as
> >>> (options flags to string + dev_specific)
> >>>
> >>> options flag can be zero if PMD does not have any generic flags nor
> >>> interested in such a scheme.
> >>> Generic flags will help at least to have some common code.
> >>>
> >>> [1]
> >>> struct rte_eth_burst_mode {
> >>>         uint64_t options;
> >>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>> };
> >>
> >> I really don't see how we can have generic flags.
> >> The flags which are proposed are just matching
> >> the functions implemented in Intel PMDs.
> >> And this is a complicate solution.
> >> Why not just returning a name for the selected Rx/Tx mode?
> >
> > +1 only for the name
> >
> > Let me clarify my earlier proposal:
> >
> > 1) The public ethdev API should return only "string" i.e the flags
> > SHOULD NOT be exposed as ethdev API
> > i.e
> > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> >
> > 2) The PMD interface  to the common code can be following
> >
> >  struct eth_pmd_burst_mode {
> >         uint64_t options;
> >          char name[128]; /* PMD specific burst mode information */
> > };
> >
> > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> >         uint16_t queue_id, struct eth_burst_mode *mode)
> >
> > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > flag to string converion(again internal to common code implemetation)
> > and concatenate with eth_pmd_burst_mode::name
> >
> > This would help to reuse some of the flags to name conversion logic
> > across all PMDs.
> > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > that case final
> > string only be eth_pmd_burst_mode::name.
> >
> > I don't see any downside with this approach and it best of both worlds.
> >
>
> I agree it will be hard or restrictive if we want to represent the all data path
> options with standardized data.
>
> But the free text string is good for logging, but not good if the application
> will get this input and give some decision with it.

I was thinking it is only for logging. But if the application needs to have
some decisions with it then below scheme is the best way,

Though I am not sure, allowing such decision in the application is good or not.
For instance, If vectorization is AVX512, What kind of decision an
application can make? If it can make some decision then, will work for
the NEON case?


>
> To combine both two, what do you think a mixed approach, similar to what Jerin
> described but both options and string is visible to application,
> and make 'options' only for vectorization information which is limited and be
> standardized:
>
> int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
>         struct rte_eth_burst_mode *mode);
>
> struct rte_eth_burst_mode {
>         uint64_t options; // This is only for VECTORIZATION mode
>         char *alternate_options;
> }
>
> since "burst_mode:options" only for vectorization, it is limited and can be easy
> to consume by applications.
> This means removing some data path options, like "BULK_ALLOC" from current struct.

ACK

>
> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> parameter and convert the 'options' to string and combine into single string as
> a helper function to the applications.
>
> And +1 to providing NULL "alternate_options" can return the size of that string.

ACK

>
> And as we find more common/standard data path options, we can move them to the
> bitfield and remove from the free text. Does it make sense?

Yes, if, we need to give provide a method to take action for
application else not.

>
Wang, Haiyue Oct. 30, 2019, 4:43 a.m. UTC | #37 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, October 30, 2019 12:38
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Wang, Haiyue <haiyue.wang@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 10:29 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> > On 10/26/2019 7:58 AM, Jerin Jacob wrote:
> > > On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >>
> > >> 25/10/2019 18:02, Jerin Jacob:
> > >>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >>>> 25/10/2019 16:08, Ferruh Yigit:
> > >>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> > >>>>>> 15/10/2019 09:51, Haiyue Wang:
> > >>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> > >>>>>>> that allows an application to retrieve the mode information about
> > >>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> > >>>>>>> like AVX2.
> > >>>>>>
> > >>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> > >>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> > >>>>>
> > >>>>> It has been discussed in the mail list and went through multiple discussions,
> > >>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> > >>>>> but when the patch is reviewed and there is no objection, why block the merge?
> > >>>>
> > >>>> I'm not saying blocking the merge.
> > >>>> My bad is that I missed the patch and I am asking for help with a notification
> > >>>> in this case. Same for Andrew I guess.
> > >>>> Note: it is merged in master and I am looking to improve this feature.
> > >>>
> > >>>>>>> +/**
> > >>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> > >>>>>>> + * Used to retrieve information about packet burst mode setting.
> > >>>>>>> + */
> > >>>>>>> +struct rte_eth_burst_mode {
> > >>>>>>> +  uint64_t options;
> > >>>>>>> +};
> > >>>>>>
> > >>>>>> Why a struct for an integer?
> > >>>>>
> > >>>>> Again by a request from me, to not need to break the API if we need to add more
> > >>>>> thing in the future.
> > >>>>
> > >>>> I would replace it with a string. This is the most flexible API.
> > >>>
> > >>> IMO, Probably, best of both worlds make a good option here,
> > >>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> > >>> and when a pass to the application, let common code make final string as
> > >>> (options flags to string + dev_specific)
> > >>>
> > >>> options flag can be zero if PMD does not have any generic flags nor
> > >>> interested in such a scheme.
> > >>> Generic flags will help at least to have some common code.
> > >>>
> > >>> [1]
> > >>> struct rte_eth_burst_mode {
> > >>>         uint64_t options;
> > >>>         char dev_specific[128]; /* PMD has specific burst mode information */
> > >>> };
> > >>
> > >> I really don't see how we can have generic flags.
> > >> The flags which are proposed are just matching
> > >> the functions implemented in Intel PMDs.
> > >> And this is a complicate solution.
> > >> Why not just returning a name for the selected Rx/Tx mode?
> > >
> > > +1 only for the name
> > >
> > > Let me clarify my earlier proposal:
> > >
> > > 1) The public ethdev API should return only "string" i.e the flags
> > > SHOULD NOT be exposed as ethdev API
> > > i.e
> > > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> > >
> > > 2) The PMD interface  to the common code can be following
> > >
> > >  struct eth_pmd_burst_mode {
> > >         uint64_t options;
> > >          char name[128]; /* PMD specific burst mode information */
> > > };
> > >
> > > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> > >         uint16_t queue_id, struct eth_burst_mode *mode)
> > >
> > > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > > flag to string converion(again internal to common code implemetation)
> > > and concatenate with eth_pmd_burst_mode::name
> > >
> > > This would help to reuse some of the flags to name conversion logic
> > > across all PMDs.
> > > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > > that case final
> > > string only be eth_pmd_burst_mode::name.
> > >
> > > I don't see any downside with this approach and it best of both worlds.
> > >
> >
> > I agree it will be hard or restrictive if we want to represent the all data path
> > options with standardized data.
> >
> > But the free text string is good for logging, but not good if the application
> > will get this input and give some decision with it.
> 
> I was thinking it is only for logging. But if the application needs to have
> some decisions with it then below scheme is the best way,
> 
> Though I am not sure, allowing such decision in the application is good or not.
> For instance, If vectorization is AVX512, What kind of decision an
> application can make? If it can make some decision then, will work for
> the NEON case?
> 
> 
> >
> > To combine both two, what do you think a mixed approach, similar to what Jerin
> > described but both options and string is visible to application,
> > and make 'options' only for vectorization information which is limited and be
> > standardized:
> >
> > int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> >         struct rte_eth_burst_mode *mode);
> >
> > struct rte_eth_burst_mode {
> >         uint64_t options; // This is only for VECTORIZATION mode
> >         char *alternate_options;
> > }
> >
> > since "burst_mode:options" only for vectorization, it is limited and can be easy
> > to consume by applications.
> > This means removing some data path options, like "BULK_ALLOC" from current struct.
> 
> ACK
> 
> >
> > 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> > parameter and convert the 'options' to string and combine into single string as
> > a helper function to the applications.
> >
> > And +1 to providing NULL "alternate_options" can return the size of that string.
> 
> ACK
> 
> >
> > And as we find more common/standard data path options, we can move them to the
> > bitfield and remove from the free text. Does it make sense?
> 
> Yes, if, we need to give provide a method to take action for
> application else not.
> 

The new member "char *alternate_options;" is assigned by PMD as static string ?
Like: mode->alternate_options = "abcd" ? Or with fixed array size, so PMD can
format it as needed ?

> >
Wang, Haiyue Oct. 30, 2019, 8:14 a.m. UTC | #38 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Wednesday, October 30, 2019 00:59
> To: Jerin Jacob <jerinjacobk@gmail.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Wang, Haiyue <haiyue.wang@intel.com>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On 10/26/2019 7:58 AM, Jerin Jacob wrote:
> > On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>
> >> 25/10/2019 18:02, Jerin Jacob:
> >>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>> that allows an application to retrieve the mode information about
> >>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>> like AVX2.
> >>>>>>
> >>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>
> >>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>
> >>>> I'm not saying blocking the merge.
> >>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>> in this case. Same for Andrew I guess.
> >>>> Note: it is merged in master and I am looking to improve this feature.
> >>>
> >>>>>>> +/**
> >>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>> + */
> >>>>>>> +struct rte_eth_burst_mode {
> >>>>>>> +  uint64_t options;
> >>>>>>> +};
> >>>>>>
> >>>>>> Why a struct for an integer?
> >>>>>
> >>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>> thing in the future.
> >>>>
> >>>> I would replace it with a string. This is the most flexible API.
> >>>
> >>> IMO, Probably, best of both worlds make a good option here,
> >>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>> and when a pass to the application, let common code make final string as
> >>> (options flags to string + dev_specific)
> >>>
> >>> options flag can be zero if PMD does not have any generic flags nor
> >>> interested in such a scheme.
> >>> Generic flags will help at least to have some common code.
> >>>
> >>> [1]
> >>> struct rte_eth_burst_mode {
> >>>         uint64_t options;
> >>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>> };
> >>
> >> I really don't see how we can have generic flags.
> >> The flags which are proposed are just matching
> >> the functions implemented in Intel PMDs.
> >> And this is a complicate solution.
> >> Why not just returning a name for the selected Rx/Tx mode?
> >
> > +1 only for the name
> >
> > Let me clarify my earlier proposal:
> >
> > 1) The public ethdev API should return only "string" i.e the flags
> > SHOULD NOT be exposed as ethdev API
> > i.e
> > int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name);
> >
> > 2) The PMD interface  to the common code can be following
> >
> >  struct eth_pmd_burst_mode {
> >         uint64_t options;
> >          char name[128]; /* PMD specific burst mode information */
> > };
> >
> > typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
> >         uint16_t queue_id, struct eth_burst_mode *mode)
> >
> > 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons
> > flag to string converion(again internal to common code implemetation)
> > and concatenate with eth_pmd_burst_mode::name
> >
> > This would help to reuse some of the flags to name conversion logic
> > across all PMDs.
> > And PMD are free to return  eth_pmd_burst_mode::options as zero in
> > that case final
> > string only be eth_pmd_burst_mode::name.
> >
> > I don't see any downside with this approach and it best of both worlds.
> >
> 
> I agree it will be hard or restrictive if we want to represent the all data path
> options with standardized data.
> 
> But the free text string is good for logging, but not good if the application
> will get this input and give some decision with it.
> 
> To combine both two, what do you think a mixed approach, similar to what Jerin
> described but both options and string is visible to application,
> and make 'options' only for vectorization information which is limited and be
> standardized:
> 
> int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> 	struct rte_eth_burst_mode *mode);
> 
> struct rte_eth_burst_mode {
> 	uint64_t options; // This is only for VECTORIZATION mode
> 	char *alternate_options;
> }
> 
> since "burst_mode:options" only for vectorization, it is limited and can be easy
> to consume by applications.
> This means removing some data path options, like "BULK_ALLOC" from current struct.
> 
> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> parameter and convert the 'options' to string and combine into single string as
> a helper function to the applications.
> 

Change:
const char *
rte_eth_burst_mode_option_name(uint64_t option)

to:
int
rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
If str == NULL, return the length of 'mode->options' ?


> And +1 to providing NULL "alternate_options" can return the size of that string.
> 

struct rte_eth_burst_mode mode;

mode.alternate_options = NULL
rte_eth_tx_burst_mode_get(0, 0, &mode) return the length of 'mode.alternate_options' ?
If so, it means that every PMD need to handle this, right ?

> And as we find more common/standard data path options, we can move them to the
> bitfield and remove from the free text. Does it make sense?
Jerin Jacob Oct. 31, 2019, 10:46 a.m. UTC | #39 
> > 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> > parameter and convert the 'options' to string and combine into single string as
> > a helper function to the applications.
> >
>
> Change:
> const char *
> rte_eth_burst_mode_option_name(uint64_t option)
>
> to:
> int
> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?


Since we are not ready to _remove_ flags in public API and rc2 time is
ticking, probably the following the change
would be enough. IMO, This API can be used only for logging purpose, I
don't want to spend too
many cycles on this discussion. I am leaving the decision to ethdev
maintainers to accommodate
the specifics of adding a string-based alternate options scheme.


[master][dpdk.org] $ git diff
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index c36c1b631..2f9d2c0a7 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
  * Ethernet device RX/TX queue packet burst mode information structure.
  * Used to retrieve information about packet burst mode setting.
  */
+#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
+
 struct rte_eth_burst_mode {
        uint64_t options;
+       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
 };
Ray Kinsella Oct. 31, 2019, 11:09 a.m. UTC | #40 
+1

On 29/10/2019 16:59, Ferruh Yigit wrote:
> On 10/26/2019 7:58 AM, Jerin Jacob wrote:
>> On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>
>>> 25/10/2019 18:02, Jerin Jacob:
[SNIP]
> 
> I agree it will be hard or restrictive if we want to represent the all data path
> options with standardized data.
> 
> But the free text string is good for logging, but not good if the application
> will get this input and give some decision with it.

Logging is probably enough for now.
In an ideal world - the PMD's would be self-describing in a machine readable 
standardized way. Similar to a GStreamer caps filter for example, that doesn't 
preclude using strings, it just means everyone needs to agree what the strings are. 

> 
> To combine both two, what do you think a mixed approach, similar to what Jerin
> described but both options and string is visible to application,
> and make 'options' only for vectorization information which is limited and be
> standardized:
> 
> int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> 	struct rte_eth_burst_mode *mode);
> 
> struct rte_eth_burst_mode {
> 	uint64_t options; // This is only for VECTORIZATION mode
> 	char *alternate_options;
> }
> 
> since "burst_mode:options" only for vectorization, it is limited and can be easy
> to consume by applications.
> This means removing some data path options, like "BULK_ALLOC" from current struct.

Makes sense, the bit fields are pretty easy to determine also. 

> 
> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> parameter and convert the 'options' to string and combine into single string as
> a helper function to the applications.
+1

> 
> And +1 to providing NULL "alternate_options" can return the size of that string.
+1

> 
> And as we find more common/standard data path options, we can move them to the
> bitfield and remove from the free text. Does it make sense?
+1 

It would allow the standardization of options to be an evolutionary process - very good idea.
Ray Kinsella Oct. 31, 2019, 11:15 a.m. UTC | #41 
On 31/10/2019 10:46, Jerin Jacob wrote:
>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
>>> parameter and convert the 'options' to string and combine into single string as
>>> a helper function to the applications.
>>>
>>
>> Change:
>> const char *
>> rte_eth_burst_mode_option_name(uint64_t option)
>>
>> to:
>> int
>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> 
> 
> Since we are not ready to _remove_ flags in public API and rc2 time is
> ticking, probably the following the change
> would be enough. IMO, This API can be used only for logging purpose, 


+1

I agree logging is enough for the moment. 

It also allows us to have the flexibility to have a discussion at a later date 
on the standardization of *some* options across PMDs. 

> I
> don't want to spend too
> many cycles on this discussion. I am leaving the decision to ethdev
> maintainers to accommodate
> the specifics of adding a string-based alternate options scheme.
> 
> 
> [master][dpdk.org] $ git diff
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index c36c1b631..2f9d2c0a7 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>   * Ethernet device RX/TX queue packet burst mode information structure.
>   * Used to retrieve information about packet burst mode setting.
>   */
> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
> +
>  struct rte_eth_burst_mode {
>         uint64_t options;
> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>  };
>
Wang, Haiyue Oct. 31, 2019, 11:16 a.m. UTC | #42 
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, October 31, 2019 18:46
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> > > 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> > > parameter and convert the 'options' to string and combine into single string as
> > > a helper function to the applications.
> > >
> >
> > Change:
> > const char *
> > rte_eth_burst_mode_option_name(uint64_t option)
> >
> > to:
> > int
> > rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> 
> 
> Since we are not ready to _remove_ flags in public API and rc2 time is
> ticking, probably the following the change
> would be enough. IMO, This API can be used only for logging purpose, I
> don't want to spend too
> many cycles on this discussion. I am leaving the decision to ethdev
> maintainers to accommodate
> the specifics of adding a string-based alternate options scheme.
> 

Thanks, Jerin.

> 
> [master][dpdk.org] $ git diff
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index c36c1b631..2f9d2c0a7 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>   * Ethernet device RX/TX queue packet burst mode information structure.
>   * Used to retrieve information about packet burst mode setting.
>   */
> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
> +
>  struct rte_eth_burst_mode {
>         uint64_t options;
> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>  };

+1
Ferruh Yigit Oct. 31, 2019, 2:58 p.m. UTC | #43 
On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Jerin Jacob <jerinjacobk@gmail.com>
>> Sent: Thursday, October 31, 2019 18:46
>> To: Wang, Haiyue <haiyue.wang@intel.com>
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>> <jerinj@marvell.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>
>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
>>>> parameter and convert the 'options' to string and combine into single string as
>>>> a helper function to the applications.
>>>>
>>>
>>> Change:
>>> const char *
>>> rte_eth_burst_mode_option_name(uint64_t option)
>>>
>>> to:
>>> int
>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
>>
>>
>> Since we are not ready to _remove_ flags in public API and rc2 time is
>> ticking, probably the following the change
>> would be enough. IMO, This API can be used only for logging purpose, I
>> don't want to spend too
>> many cycles on this discussion. I am leaving the decision to ethdev
>> maintainers to accommodate
>> the specifics of adding a string-based alternate options scheme.
>>
> 
> Thanks, Jerin.
> 
>>
>> [master][dpdk.org] $ git diff
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index c36c1b631..2f9d2c0a7 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>>   * Ethernet device RX/TX queue packet burst mode information structure.
>>   * Used to retrieve information about packet burst mode setting.
>>   */
>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128

Should we make it bigger to prevent ABI break just because of this later? Like
512 or bigger?

>> +
>>  struct rte_eth_burst_mode {
>>         uint64_t options;
>> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>>  };
> 
> +1
> 

+1

It is not as flexible as getting the size from the PMD but much simpler, both
for the user and PMD.

And what about dropping the 'rte_eth_burst_mode_option_name()', if
'rte_eth_tx_burst_mode_get()' converts the 'options' to text
('alternate_options') as Jerin suggested, we can drop it.

So only difference from what Jerin suggested will be keeping 'uint64_t options'
public for known/limited standardized options, which is currently only for
vectorization information.
Wang, Haiyue Oct. 31, 2019, 3:07 p.m. UTC | #44 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Thursday, October 31, 2019 22:58
> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Jerin Jacob <jerinjacobk@gmail.com>
> >> Sent: Thursday, October 31, 2019 18:46
> >> To: Wang, Haiyue <haiyue.wang@intel.com>
> >> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
> >> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> >> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> >> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> >> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >> <jerinj@marvell.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>
> >>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> >>>> parameter and convert the 'options' to string and combine into single string as
> >>>> a helper function to the applications.
> >>>>
> >>>
> >>> Change:
> >>> const char *
> >>> rte_eth_burst_mode_option_name(uint64_t option)
> >>>
> >>> to:
> >>> int
> >>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> >>
> >>
> >> Since we are not ready to _remove_ flags in public API and rc2 time is
> >> ticking, probably the following the change
> >> would be enough. IMO, This API can be used only for logging purpose, I
> >> don't want to spend too
> >> many cycles on this discussion. I am leaving the decision to ethdev
> >> maintainers to accommodate
> >> the specifics of adding a string-based alternate options scheme.
> >>
> >
> > Thanks, Jerin.
> >
> >>
> >> [master][dpdk.org] $ git diff
> >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> >> index c36c1b631..2f9d2c0a7 100644
> >> --- a/lib/librte_ethdev/rte_ethdev.h
> >> +++ b/lib/librte_ethdev/rte_ethdev.h
> >> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
> >>   * Ethernet device RX/TX queue packet burst mode information structure.
> >>   * Used to retrieve information about packet burst mode setting.
> >>   */
> >> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
> 
> Should we make it bigger to prevent ABI break just because of this later? Like
> 512 or bigger?
> 

Use 1024 ?

> >> +
> >>  struct rte_eth_burst_mode {
> >>         uint64_t options;
> >> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> >>  };
> >
> > +1
> >
> 
> +1
> 
> It is not as flexible as getting the size from the PMD but much simpler, both
> for the user and PMD.
> 
> And what about dropping the 'rte_eth_burst_mode_option_name()', if
> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
> ('alternate_options') as Jerin suggested, we can drop it.
> 
> So only difference from what Jerin suggested will be keeping 'uint64_t options'
> public for known/limited standardized options, which is currently only for
> vectorization information.

Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
rte_eth_rx/tx_burst_mode_get() ?

But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
When 'name' is NULL, return the buffer size will be used. If non-NULL, format
all the options. This will reduce the twice PMDs calls: 
	dev->dev_ops->rx/tx_burst_mode_get
And leave the filled *mode for application.
Ferruh Yigit Oct. 31, 2019, 3:29 p.m. UTC | #45 
On 10/31/2019 3:07 PM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Sent: Thursday, October 31, 2019 22:58
>> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
>> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
>> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
>> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
>> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>> <jerinj@marvell.com>
>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>
>> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
>>>> -----Original Message-----
>>>> From: Jerin Jacob <jerinjacobk@gmail.com>
>>>> Sent: Thursday, October 31, 2019 18:46
>>>> To: Wang, Haiyue <haiyue.wang@intel.com>
>>>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
>>>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
>>>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
>>>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
>> Hemminger
>>>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
>>>> <jerinj@marvell.com>
>>>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
>>>>
>>>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
>>>>>> parameter and convert the 'options' to string and combine into single string as
>>>>>> a helper function to the applications.
>>>>>>
>>>>>
>>>>> Change:
>>>>> const char *
>>>>> rte_eth_burst_mode_option_name(uint64_t option)
>>>>>
>>>>> to:
>>>>> int
>>>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
>>>>
>>>>
>>>> Since we are not ready to _remove_ flags in public API and rc2 time is
>>>> ticking, probably the following the change
>>>> would be enough. IMO, This API can be used only for logging purpose, I
>>>> don't want to spend too
>>>> many cycles on this discussion. I am leaving the decision to ethdev
>>>> maintainers to accommodate
>>>> the specifics of adding a string-based alternate options scheme.
>>>>
>>>
>>> Thanks, Jerin.
>>>
>>>>
>>>> [master][dpdk.org] $ git diff
>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>>>> index c36c1b631..2f9d2c0a7 100644
>>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
>>>>   * Ethernet device RX/TX queue packet burst mode information structure.
>>>>   * Used to retrieve information about packet burst mode setting.
>>>>   */
>>>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
>>
>> Should we make it bigger to prevent ABI break just because of this later? Like
>> 512 or bigger?
>>
> 
> Use 1024 ?
> 
>>>> +
>>>>  struct rte_eth_burst_mode {
>>>>         uint64_t options;
>>>> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
>>>>  };
>>>
>>> +1
>>>
>>
>> +1
>>
>> It is not as flexible as getting the size from the PMD but much simpler, both
>> for the user and PMD.
>>
>> And what about dropping the 'rte_eth_burst_mode_option_name()', if
>> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
>> ('alternate_options') as Jerin suggested, we can drop it.
>>
>> So only difference from what Jerin suggested will be keeping 'uint64_t options'
>> public for known/limited standardized options, which is currently only for
>> vectorization information.
> 
> Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
> rte_eth_rx/tx_burst_mode_get() ?

What do you mean keep current design, not having a string field in "struct
rte_eth_burst_mode"?

> 
> But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
> 'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
> When 'name' is NULL, return the buffer size will be used. If non-NULL, format
> all the options. This will reduce the twice PMDs calls: 
> 	dev->dev_ops->rx/tx_burst_mode_get
> And leave the filled *mode for application.
> 

we need "dev_ops->rx/tx_burst_mode_get" to get information from PMDs, except
from 'uint64_t options' the provided information already as string, if the
ethdev APIs for these devops converts 'uint64_t options' to string and append to
'alternate_options', application will already have all the string, so won't need
this 'rte_eth_burst_mode_option_name()' API anymore.
Wang, Haiyue Oct. 31, 2019, 3:54 p.m. UTC | #46 
> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Thursday, October 31, 2019 23:30
> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On 10/31/2019 3:07 PM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Sent: Thursday, October 31, 2019 22:58
> >> To: Wang, Haiyue <haiyue.wang@intel.com>; Jerin Jacob <jerinjacobk@gmail.com>
> >> Cc: Thomas Monjalon <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Ye, Xiaolong
> >> <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard
> >> <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew Rybchenko
> >> <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> >> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >> <jerinj@marvell.com>
> >> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>
> >> On 10/31/2019 11:16 AM, Wang, Haiyue wrote:
> >>>> -----Original Message-----
> >>>> From: Jerin Jacob <jerinjacobk@gmail.com>
> >>>> Sent: Thursday, October 31, 2019 18:46
> >>>> To: Wang, Haiyue <haiyue.wang@intel.com>
> >>>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>; dpdk-dev
> >>>> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> >>>> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> >>>> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> >> Hemminger
> >>>> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> >>>> <jerinj@marvell.com>
> >>>> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> >>>>
> >>>>>> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> >>>>>> parameter and convert the 'options' to string and combine into single string as
> >>>>>> a helper function to the applications.
> >>>>>>
> >>>>>
> >>>>> Change:
> >>>>> const char *
> >>>>> rte_eth_burst_mode_option_name(uint64_t option)
> >>>>>
> >>>>> to:
> >>>>> int
> >>>>> rte_eth_burst_mode_option_name(struct rte_eth_burst_mode *mode, char *str) ?
> >>>>
> >>>>
> >>>> Since we are not ready to _remove_ flags in public API and rc2 time is
> >>>> ticking, probably the following the change
> >>>> would be enough. IMO, This API can be used only for logging purpose, I
> >>>> don't want to spend too
> >>>> many cycles on this discussion. I am leaving the decision to ethdev
> >>>> maintainers to accommodate
> >>>> the specifics of adding a string-based alternate options scheme.
> >>>>
> >>>
> >>> Thanks, Jerin.
> >>>
> >>>>
> >>>> [master][dpdk.org] $ git diff
> >>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> >>>> index c36c1b631..2f9d2c0a7 100644
> >>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>>> @@ -1272,8 +1272,11 @@ enum rte_eth_burst_mode_option {
> >>>>   * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>   * Used to retrieve information about packet burst mode setting.
> >>>>   */
> >>>> +#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 128
> >>
> >> Should we make it bigger to prevent ABI break just because of this later? Like
> >> 512 or bigger?
> >>
> >
> > Use 1024 ?
> >
> >>>> +
> >>>>  struct rte_eth_burst_mode {
> >>>>         uint64_t options;
> >>>> +       char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
> >>>>  };
> >>>
> >>> +1
> >>>
> >>
> >> +1
> >>
> >> It is not as flexible as getting the size from the PMD but much simpler, both
> >> for the user and PMD.
> >>
> >> And what about dropping the 'rte_eth_burst_mode_option_name()', if
> >> 'rte_eth_tx_burst_mode_get()' converts the 'options' to text
> >> ('alternate_options') as Jerin suggested, we can drop it.
> >>
> >> So only difference from what Jerin suggested will be keeping 'uint64_t options'
> >> public for known/limited standardized options, which is currently only for
> >> vectorization information.
> >
> > Since 'struct rte_eth_burst_mode' will be public, how about keep current design for
> > rte_eth_rx/tx_burst_mode_get() ?
> 
> What do you mean keep current design, not having a string field in "struct
> rte_eth_burst_mode"?
> 
> >
> > But change 'const char *rte_eth_burst_mode_option_name(uint64_t option)' to
> > 'int rte_eth_burst_mode_name(struct rte_eth_burst_mode *mode, char *name)' ?
> > When 'name' is NULL, return the buffer size will be used. If non-NULL, format
> > all the options. This will reduce the twice PMDs calls:
> > 	dev->dev_ops->rx/tx_burst_mode_get
> > And leave the filled *mode for application.
> >
> 
> we need "dev_ops->rx/tx_burst_mode_get" to get information from PMDs, except
> from 'uint64_t options' the provided information already as string, if the
> ethdev APIs for these devops converts 'uint64_t options' to string and append to
> 'alternate_options', application will already have all the string, so won't need
> this 'rte_eth_burst_mode_option_name()' API anymore.

Got it now. Thanks!
Ray Kinsella Nov. 3, 2019, 8:35 p.m. UTC | #47 
On 29/10/2019 14:27, Ferruh Yigit wrote:
> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>> 26/10/2019 11:23, Wang, Haiyue:
>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>> like AVX2.
>>>>>>>>>>
>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>
>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>
>>>>>>>> I'm not saying blocking the merge.
>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>
>>>>>>>>>>> +/**
>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>> + */
>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>> +  uint64_t options;
>>>>>>>>>>> +};
>>>>>>>>>>
>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>
>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>> thing in the future.
>>>>>>>>
>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>
>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>> (options flags to string + dev_specific)
>>>>>>>
>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>> interested in such a scheme.
>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>
>>>>>>> [1]
>>>>>>> struct rte_eth_burst_mode {
>>>>>>>         uint64_t options;
>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>> };
>>>>>>
>>>>>> I really don't see how we can have generic flags.
>>>>>> The flags which are proposed are just matching
>>>>>> the functions implemented in Intel PMDs.
>>>>>> And this is a complicate solution.
>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>
>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>> variety of CPU architectures."
>>>>
>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>> They just match some features of the Intel PMDs.
>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>> You totally missed the point of generic burst mode description.
>>>>
>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>> just simple bit test.
>>>>>
>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>
>>>> I have no word!
>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>> Or depending on which offloads are handled?
>>>>
>>>> Again, the instruction set used by the function is a small part
>>>> of the burst mode optimization.
>>>>
>>>> So you did not reply to my question:
>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>
>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>> application to do further processing, strcmp, strstr ? Not so nice
>>> for C code, and it is not so standard, So switch it to bit definition.
>>
>> Again, please answer my question: why do you need it?
>> I think it is just informative, that's why a string should be enough.
>> I am clearly against the bitmap because it is way too much restrictive.
>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>> What you would like to know is whether it is processing packets 4 by 4,
>> for instance, or to know which offload is supported, or what hardware trick
>> is used in the datapath design.
>> There are so many options in a datapath design that it cannot be
>> represented with a bitmap. And it makes no sense to have some design
>> criterias more important than others.
>> I Cc an Intel architect (Edwin) who could explain you how much
>> a datapath design is more complicate than just using AVX instructions.
> 
> As I understand this is to let applications to give informed decision based on
> what vectorization is used in the driver, currently this is not know by the
> application.
> 
> And as previously replied, the main target of the API is to define the vector
> path, not all optimizations, so the number is limited.
> There are many optimization in the data path, I agree we may not represent all
> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> causing this confusion, perhaps we can remove them.
> 
> And if the requirement from the application is just informative, I would agree
> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> is the main API to provide the information and
> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> this information.
> 

Well look we have a general deficit of information about what is happening under 
the covers in DPDK. The end user may get wildly different performance characteristics 
based on the DPDK configuration. Simple example is using flow director causes the i40e 
PMD to switch to using a scalar code path, and performance may as much as half.

This can cause no end of head-scratching in consuming products, I have done some 
of that head scratching myself, it is a usability nightmare. 

FD.io VPP tries to work around this by mining the call stack, to give the user _some_
kind of information about what is happening. These kind of heroics should not be necessary.

For exactly the same reasons as telemetry, we should be trying to give the users as much 
information as possible, in as standard as format as possible. Otherwise DPDK 
becomes arcane leaving the user running gdb to understand what is going on, as I 
frequently do. 

Finally, again for the same reasons as telemetry, I would say that machine readable is the 
ideal here.


              Name                Idx   Link  Hardware
FortyGigabitEthernet86/0/0         1     up   FortyGigabitEthernet86/0/0
  Link speed: 40 Gbps
  Ethernet address 3c:fd:fe:bc:b2:b0
  Intel X710/XL710 Family
    carrier up full duplex mtu 9206
    flags: admin-up pmd rx-ip4-cksum
    rx: queues 2 (max 320), desc 1024 (min 64 max 4096 align 32)
    tx: queues 3 (max 320), desc 1024 (min 64 max 4096 align 32)
    pci: device 8086:1583 subsystem 8086:0001 address 0000:86:00.00 numa 1
    max rx packet len: 9728
    promiscuous: unicast off all-multicast on
    vlan offload: strip off filter off qinq off
    rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip
                       outer-ipv4-cksum vlan-filter vlan-extend jumbo-frame
                       scatter keep-crc
    rx offload active: ipv4-cksum
    tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum
                       tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso
                       gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs
                       mbuf-fast-free
    tx offload active: none
    rss avail:         ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other ipv6-frag
                       ipv6-tcp ipv6-udp ipv6-sctp ipv6-other l2-payload
    rss active:        ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv6-frag ipv6-tcp
                       ipv6-udp ipv6-other
    tx burst function: i40e_xmit_pkts_vec_avx2 <--------------------------------
    rx burst function: i40e_recv_pkts_vec_avx2 <--------------------------------

    tx frames ok                               3303819336013
    tx bytes ok                              198229160160780
    rx frames ok                              17503181209363
    rx bytes ok                              205944346015764
    rx missed                                     2973393096
Thomas Monjalon Nov. 3, 2019, 10:41 p.m. UTC | #48 
03/11/2019 21:35, Ray Kinsella:
> On 29/10/2019 14:27, Ferruh Yigit wrote:
> > On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >> 26/10/2019 11:23, Wang, Haiyue:
> >>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>> like AVX2.
> >>>>>>>>>>
> >>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>
> >>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>
> >>>>>>>> I'm not saying blocking the merge.
> >>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>> +};
> >>>>>>>>>>
> >>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>
> >>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>> thing in the future.
> >>>>>>>>
> >>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>
> >>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>> (options flags to string + dev_specific)
> >>>>>>>
> >>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>> interested in such a scheme.
> >>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>
> >>>>>>> [1]
> >>>>>>> struct rte_eth_burst_mode {
> >>>>>>>         uint64_t options;
> >>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>> };
> >>>>>>
> >>>>>> I really don't see how we can have generic flags.
> >>>>>> The flags which are proposed are just matching
> >>>>>> the functions implemented in Intel PMDs.
> >>>>>> And this is a complicate solution.
> >>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>
> >>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>> variety of CPU architectures."
> >>>>
> >>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>> They just match some features of the Intel PMDs.
> >>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>> You totally missed the point of generic burst mode description.
> >>>>
> >>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>> just simple bit test.
> >>>>>
> >>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>
> >>>> I have no word!
> >>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>> Or depending on which offloads are handled?
> >>>>
> >>>> Again, the instruction set used by the function is a small part
> >>>> of the burst mode optimization.
> >>>>
> >>>> So you did not reply to my question:
> >>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>
> >>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>> application to do further processing, strcmp, strstr ? Not so nice
> >>> for C code, and it is not so standard, So switch it to bit definition.
> >>
> >> Again, please answer my question: why do you need it?
> >> I think it is just informative, that's why a string should be enough.
> >> I am clearly against the bitmap because it is way too much restrictive.
> >> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >> What you would like to know is whether it is processing packets 4 by 4,
> >> for instance, or to know which offload is supported, or what hardware trick
> >> is used in the datapath design.
> >> There are so many options in a datapath design that it cannot be
> >> represented with a bitmap. And it makes no sense to have some design
> >> criterias more important than others.
> >> I Cc an Intel architect (Edwin) who could explain you how much
> >> a datapath design is more complicate than just using AVX instructions.
> > 
> > As I understand this is to let applications to give informed decision based on
> > what vectorization is used in the driver, currently this is not know by the
> > application.
> > 
> > And as previously replied, the main target of the API is to define the vector
> > path, not all optimizations, so the number is limited.

No!
The name of this API is "burst mode information",
not "vector instructions used".
I think the main error is that in Intel PMDs,
each Rx/Tx function use different vector instructions.
So you generalize that knowing the vectors instructions
will give you a good information about the performance.
But this is generally wrong!
The right level of infos is much more complex.

> > There are many optimization in the data path, I agree we may not represent all
> > of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> > causing this confusion, perhaps we can remove them.
> > 
> > And if the requirement from the application is just informative, I would agree
> > that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> > is the main API to provide the information and
> > 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> > this information.
> > 
> 
> Well look we have a general deficit of information about what is happening under 
> the covers in DPDK. The end user may get wildly different performance characteristics 
> based on the DPDK configuration. Simple example is using flow director causes the i40e 
> PMD to switch to using a scalar code path, and performance may as much as half.
> 
> This can cause no end of head-scratching in consuming products, I have done some 
> of that head scratching myself, it is a usability nightmare. 
> 
> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> kind of information about what is happening. These kind of heroics should not be necessary.
> 
> For exactly the same reasons as telemetry, we should be trying to give the users as much 
> information as possible, in as standard as format as possible. Otherwise DPDK 
> becomes arcane leaving the user running gdb to understand what is going on, as I 
> frequently do.

I agree we must provide a clue to understand the performance result.
As Stephen commented at the very beginning, a log is enough for such debug.
But his comment was ignored. You wanted an API, fine.
I am OK to have an API to request infos which are also in logs.

> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
> ideal here.

I disagree here. There is no need to make this info machine readable.
We want a clue about the optimizations which are all about creativity.
And we cannot make creativity of developers "machine readable".
Ray Kinsella Nov. 4, 2019, 9:49 a.m. UTC | #49 
On 03/11/2019 22:41, Thomas Monjalon wrote:
> 03/11/2019 21:35, Ray Kinsella:
>> On 29/10/2019 14:27, Ferruh Yigit wrote:
>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>>>> 26/10/2019 11:23, Wang, Haiyue:
>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>>>> like AVX2.
>>>>>>>>>>>>
>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>>>
>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>>>
>>>>>>>>>> I'm not saying blocking the merge.
>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>>>
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>>>> +  uint64_t options;
>>>>>>>>>>>>> +};
>>>>>>>>>>>>
>>>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>>>
>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>>>> thing in the future.
>>>>>>>>>>
>>>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>>>
>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>>>> (options flags to string + dev_specific)
>>>>>>>>>
>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>>>> interested in such a scheme.
>>>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> struct rte_eth_burst_mode {
>>>>>>>>>         uint64_t options;
>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>>>> };
>>>>>>>>
>>>>>>>> I really don't see how we can have generic flags.
>>>>>>>> The flags which are proposed are just matching
>>>>>>>> the functions implemented in Intel PMDs.
>>>>>>>> And this is a complicate solution.
>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>
>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>>>> variety of CPU architectures."
>>>>>>
>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>>>> They just match some features of the Intel PMDs.
>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>>>> You totally missed the point of generic burst mode description.
>>>>>>
>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>>>> just simple bit test.
>>>>>>>
>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>>>
>>>>>> I have no word!
>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>>>> Or depending on which offloads are handled?
>>>>>>
>>>>>> Again, the instruction set used by the function is a small part
>>>>>> of the burst mode optimization.
>>>>>>
>>>>>> So you did not reply to my question:
>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>
>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>>>> application to do further processing, strcmp, strstr ? Not so nice
>>>>> for C code, and it is not so standard, So switch it to bit definition.
>>>>
>>>> Again, please answer my question: why do you need it?
>>>> I think it is just informative, that's why a string should be enough.
>>>> I am clearly against the bitmap because it is way too much restrictive.
>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>>>> What you would like to know is whether it is processing packets 4 by 4,
>>>> for instance, or to know which offload is supported, or what hardware trick
>>>> is used in the datapath design.
>>>> There are so many options in a datapath design that it cannot be
>>>> represented with a bitmap. And it makes no sense to have some design
>>>> criterias more important than others.
>>>> I Cc an Intel architect (Edwin) who could explain you how much
>>>> a datapath design is more complicate than just using AVX instructions.
>>>
>>> As I understand this is to let applications to give informed decision based on
>>> what vectorization is used in the driver, currently this is not know by the
>>> application.
>>>
>>> And as previously replied, the main target of the API is to define the vector
>>> path, not all optimizations, so the number is limited.
> 
> No!
> The name of this API is "burst mode information",
> not "vector instructions used".
> I think the main error is that in Intel PMDs,
> each Rx/Tx function use different vector instructions.
> So you generalize that knowing the vectors instructions
> will give you a good information about the performance.
> But this is generally wrong!
> The right level of infos is much more complex.

I don't think anyone was suggesting limiting it to purely describing PMD optimization 
with vector instructions. If there are other commonalities let's describe those also. 

Vectorization was thought to be a good starting point - IMHO it is.

> 
>>> There are many optimization in the data path, I agree we may not represent all
>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
>>> causing this confusion, perhaps we can remove them.
>>>
>>> And if the requirement from the application is just informative, I would agree
>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
>>> is the main API to provide the information and
>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
>>> this information.
>>>
>>
>> Well look we have a general deficit of information about what is happening under 
>> the covers in DPDK. The end user may get wildly different performance characteristics 
>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
>> PMD to switch to using a scalar code path, and performance may as much as half.
>>
>> This can cause no end of head-scratching in consuming products, I have done some 
>> of that head scratching myself, it is a usability nightmare. 
>>
>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
>> kind of information about what is happening. These kind of heroics should not be necessary.
>>
>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
>> information as possible, in as standard as format as possible. Otherwise DPDK 
>> becomes arcane leaving the user running gdb to understand what is going on, as I 
>> frequently do.
> 
> I agree we must provide a clue to understand the performance result.
> As Stephen commented at the very beginning, a log is enough for such debug.
> But his comment was ignored. 

Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
It's very brittle and arcane way to provide information, if nothing else. 

> You wanted an API, fine.
> I am OK to have an API to request infos which are also in logs.

I would point out that an API to query meta-data is common practice else where.
GStreamer GstCaps and Linux Sysfs are the closest example I can think of.

> 
>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
>> ideal here.
> 
> I disagree here. There is no need to make this info machine readable.
> We want a clue about the optimizations which are all about creativity.
> And we cannot make creativity of developers "machine readable".

I am more concerned about the creativity in how developers describe optimizations. 
If there is no standardization of strings (or bits), the API will be challenging to use. 

Ray K
Thomas Monjalon Nov. 4, 2019, 9:54 a.m. UTC | #50 
04/11/2019 10:49, Ray Kinsella:
> On 03/11/2019 22:41, Thomas Monjalon wrote:
> > 03/11/2019 21:35, Ray Kinsella:
> >> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>
> >>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>
> >>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>>>> +};
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>
> >>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>> thing in the future.
> >>>>>>>>>>
> >>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>
> >>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>
> >>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>> interested in such a scheme.
> >>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>         uint64_t options;
> >>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>> };
> >>>>>>>>
> >>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>> The flags which are proposed are just matching
> >>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>> And this is a complicate solution.
> >>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>
> >>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>> variety of CPU architectures."
> >>>>>>
> >>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>> They just match some features of the Intel PMDs.
> >>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>> You totally missed the point of generic burst mode description.
> >>>>>>
> >>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>> just simple bit test.
> >>>>>>>
> >>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>
> >>>>>> I have no word!
> >>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>> Or depending on which offloads are handled?
> >>>>>>
> >>>>>> Again, the instruction set used by the function is a small part
> >>>>>> of the burst mode optimization.
> >>>>>>
> >>>>>> So you did not reply to my question:
> >>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>
> >>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>
> >>>> Again, please answer my question: why do you need it?
> >>>> I think it is just informative, that's why a string should be enough.
> >>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>> for instance, or to know which offload is supported, or what hardware trick
> >>>> is used in the datapath design.
> >>>> There are so many options in a datapath design that it cannot be
> >>>> represented with a bitmap. And it makes no sense to have some design
> >>>> criterias more important than others.
> >>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>> a datapath design is more complicate than just using AVX instructions.
> >>>
> >>> As I understand this is to let applications to give informed decision based on
> >>> what vectorization is used in the driver, currently this is not know by the
> >>> application.
> >>>
> >>> And as previously replied, the main target of the API is to define the vector
> >>> path, not all optimizations, so the number is limited.
> > 
> > No!
> > The name of this API is "burst mode information",
> > not "vector instructions used".
> > I think the main error is that in Intel PMDs,
> > each Rx/Tx function use different vector instructions.
> > So you generalize that knowing the vectors instructions
> > will give you a good information about the performance.
> > But this is generally wrong!
> > The right level of infos is much more complex.
> 
> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
> with vector instructions. If there are other commonalities let's describe those also. 
> 
> Vectorization was thought to be a good starting point - IMHO it is.
> 
> > 
> >>> There are many optimization in the data path, I agree we may not represent all
> >>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>> causing this confusion, perhaps we can remove them.
> >>>
> >>> And if the requirement from the application is just informative, I would agree
> >>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>> is the main API to provide the information and
> >>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>> this information.
> >>>
> >>
> >> Well look we have a general deficit of information about what is happening under 
> >> the covers in DPDK. The end user may get wildly different performance characteristics 
> >> based on the DPDK configuration. Simple example is using flow director causes the i40e 
> >> PMD to switch to using a scalar code path, and performance may as much as half.
> >>
> >> This can cause no end of head-scratching in consuming products, I have done some 
> >> of that head scratching myself, it is a usability nightmare. 
> >>
> >> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >> kind of information about what is happening. These kind of heroics should not be necessary.
> >>
> >> For exactly the same reasons as telemetry, we should be trying to give the users as much 
> >> information as possible, in as standard as format as possible. Otherwise DPDK 
> >> becomes arcane leaving the user running gdb to understand what is going on, as I 
> >> frequently do.
> > 
> > I agree we must provide a clue to understand the performance result.
> > As Stephen commented at the very beginning, a log is enough for such debug.
> > But his comment was ignored. 
> 
> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> It's very brittle and arcane way to provide information, if nothing else. 
> 
> > You wanted an API, fine.
> > I am OK to have an API to request infos which are also in logs.
> 
> I would point out that an API to query meta-data is common practice else where.
> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> 
> > 
> >> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
> >> ideal here.
> > 
> > I disagree here. There is no need to make this info machine readable.
> > We want a clue about the optimizations which are all about creativity.
> > And we cannot make creativity of developers "machine readable".
> 
> I am more concerned about the creativity in how developers describe optimizations. 
> If there is no standardization of strings (or bits), the API will be challenging to use. 

No it won't be challenging because it will be just a string to print.
The challenge is trying to fix the design characteristics in an API.
Ray Kinsella Nov. 4, 2019, 10:03 a.m. UTC | #51 
On 04/11/2019 09:54, Thomas Monjalon wrote:
> 04/11/2019 10:49, Ray Kinsella:
>> On 03/11/2019 22:41, Thomas Monjalon wrote:
>>> 03/11/2019 21:35, Ray Kinsella:
>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>>>>>> 26/10/2019 11:23, Wang, Haiyue:
>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>>>>>> like AVX2.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not saying blocking the merge.
>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>>>>>
>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>>>>>> +  uint64_t options;
>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>>>>>> thing in the future.
>>>>>>>>>>>>
>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>>>>>
>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>>>>>> (options flags to string + dev_specific)
>>>>>>>>>>>
>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>>>>>> interested in such a scheme.
>>>>>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> struct rte_eth_burst_mode {
>>>>>>>>>>>         uint64_t options;
>>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> I really don't see how we can have generic flags.
>>>>>>>>>> The flags which are proposed are just matching
>>>>>>>>>> the functions implemented in Intel PMDs.
>>>>>>>>>> And this is a complicate solution.
>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>
>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>>>>>> variety of CPU architectures."
>>>>>>>>
>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>>>>>> They just match some features of the Intel PMDs.
>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>>>>>> You totally missed the point of generic burst mode description.
>>>>>>>>
>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>>>>>> just simple bit test.
>>>>>>>>>
>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>>>>>
>>>>>>>> I have no word!
>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>>>>>> Or depending on which offloads are handled?
>>>>>>>>
>>>>>>>> Again, the instruction set used by the function is a small part
>>>>>>>> of the burst mode optimization.
>>>>>>>>
>>>>>>>> So you did not reply to my question:
>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>
>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
>>>>>>
>>>>>> Again, please answer my question: why do you need it?
>>>>>> I think it is just informative, that's why a string should be enough.
>>>>>> I am clearly against the bitmap because it is way too much restrictive.
>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>>>>>> What you would like to know is whether it is processing packets 4 by 4,
>>>>>> for instance, or to know which offload is supported, or what hardware trick
>>>>>> is used in the datapath design.
>>>>>> There are so many options in a datapath design that it cannot be
>>>>>> represented with a bitmap. And it makes no sense to have some design
>>>>>> criterias more important than others.
>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
>>>>>> a datapath design is more complicate than just using AVX instructions.
>>>>>
>>>>> As I understand this is to let applications to give informed decision based on
>>>>> what vectorization is used in the driver, currently this is not know by the
>>>>> application.
>>>>>
>>>>> And as previously replied, the main target of the API is to define the vector
>>>>> path, not all optimizations, so the number is limited.
>>>
>>> No!
>>> The name of this API is "burst mode information",
>>> not "vector instructions used".
>>> I think the main error is that in Intel PMDs,
>>> each Rx/Tx function use different vector instructions.
>>> So you generalize that knowing the vectors instructions
>>> will give you a good information about the performance.
>>> But this is generally wrong!
>>> The right level of infos is much more complex.
>>
>> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
>> with vector instructions. If there are other commonalities let's describe those also. 
>>
>> Vectorization was thought to be a good starting point - IMHO it is.
>>
>>>
>>>>> There are many optimization in the data path, I agree we may not represent all
>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
>>>>> causing this confusion, perhaps we can remove them.
>>>>>
>>>>> And if the requirement from the application is just informative, I would agree
>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
>>>>> is the main API to provide the information and
>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
>>>>> this information.
>>>>>
>>>>
>>>> Well look we have a general deficit of information about what is happening under 
>>>> the covers in DPDK. The end user may get wildly different performance characteristics 
>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
>>>> PMD to switch to using a scalar code path, and performance may as much as half.
>>>>
>>>> This can cause no end of head-scratching in consuming products, I have done some 
>>>> of that head scratching myself, it is a usability nightmare. 
>>>>
>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
>>>> kind of information about what is happening. These kind of heroics should not be necessary.
>>>>
>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
>>>> information as possible, in as standard as format as possible. Otherwise DPDK 
>>>> becomes arcane leaving the user running gdb to understand what is going on, as I 
>>>> frequently do.
>>>
>>> I agree we must provide a clue to understand the performance result.
>>> As Stephen commented at the very beginning, a log is enough for such debug.
>>> But his comment was ignored. 
>>
>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
>> It's very brittle and arcane way to provide information, if nothing else. 
>>
>>> You wanted an API, fine.
>>> I am OK to have an API to request infos which are also in logs.
>>
>> I would point out that an API to query meta-data is common practice else where.
>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
>>
>>>
>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
>>>> ideal here.
>>>
>>> I disagree here. There is no need to make this info machine readable.
>>> We want a clue about the optimizations which are all about creativity.
>>> And we cannot make creativity of developers "machine readable".
>>
>> I am more concerned about the creativity in how developers describe optimizations. 
>> If there is no standardization of strings (or bits), the API will be challenging to use. 
> 
> No it won't be challenging because it will be just a string to print.

Well the challenge is getting everyone to use the same set of strings, 
such that what is returned by the API has common meaning. 

I am fine with strings.
So long as we have a method of encouraging folks to use a standard set were possible.

> The challenge is trying to fix the design characteristics in an API.

I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start. 
Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had.
Wang, Haiyue Nov. 4, 2019, 10:46 a.m. UTC | #52 
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, November 4, 2019 18:03
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; 'Damjan Marion' <dmarion@me.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> viacheslavo@mellanox.com; stephen@networkplumber.org; arybchenko@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 
> 
> On 04/11/2019 09:54, Thomas Monjalon wrote:
> > 04/11/2019 10:49, Ray Kinsella:
> >> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>> 03/11/2019 21:35, Ray Kinsella:
> >>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>
> >>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>
> >>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>
> >>>>>>>>>>> [1]
> >>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>         uint64_t options;
> >>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>> };
> >>>>>>>>>>
> >>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>
> >>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>> variety of CPU architectures."
> >>>>>>>>
> >>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>
> >>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>> just simple bit test.
> >>>>>>>>>
> >>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>
> >>>>>>>> I have no word!
> >>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>
> >>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>> of the burst mode optimization.
> >>>>>>>>
> >>>>>>>> So you did not reply to my question:
> >>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>
> >>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>
> >>>>>> Again, please answer my question: why do you need it?
> >>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>> is used in the datapath design.
> >>>>>> There are so many options in a datapath design that it cannot be
> >>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>> criterias more important than others.
> >>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>
> >>>>> As I understand this is to let applications to give informed decision based on
> >>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>> application.
> >>>>>
> >>>>> And as previously replied, the main target of the API is to define the vector
> >>>>> path, not all optimizations, so the number is limited.
> >>>
> >>> No!
> >>> The name of this API is "burst mode information",
> >>> not "vector instructions used".
> >>> I think the main error is that in Intel PMDs,
> >>> each Rx/Tx function use different vector instructions.
> >>> So you generalize that knowing the vectors instructions
> >>> will give you a good information about the performance.
> >>> But this is generally wrong!
> >>> The right level of infos is much more complex.
> >>
> >> I don't think anyone was suggesting limiting it to purely describing PMD optimization
> >> with vector instructions. If there are other commonalities let's describe those also.
> >>
> >> Vectorization was thought to be a good starting point - IMHO it is.
> >>
> >>>
> >>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>> causing this confusion, perhaps we can remove them.
> >>>>>
> >>>>> And if the requirement from the application is just informative, I would agree
> >>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>> is the main API to provide the information and
> >>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>> this information.
> >>>>>
> >>>>
> >>>> Well look we have a general deficit of information about what is happening under
> >>>> the covers in DPDK. The end user may get wildly different performance characteristics
> >>>> based on the DPDK configuration. Simple example is using flow director causes the i40e
> >>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>
> >>>> This can cause no end of head-scratching in consuming products, I have done some
> >>>> of that head scratching myself, it is a usability nightmare.
> >>>>
> >>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>
> >>>> For exactly the same reasons as telemetry, we should be trying to give the users as much
> >>>> information as possible, in as standard as format as possible. Otherwise DPDK
> >>>> becomes arcane leaving the user running gdb to understand what is going on, as I
> >>>> frequently do.
> >>>
> >>> I agree we must provide a clue to understand the performance result.
> >>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>> But his comment was ignored.
> >>
> >> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >> It's very brittle and arcane way to provide information, if nothing else.
> >>
> >>> You wanted an API, fine.
> >>> I am OK to have an API to request infos which are also in logs.
> >>
> >> I would point out that an API to query meta-data is common practice else where.
> >> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>
> >>>
> >>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the
> >>>> ideal here.
> >>>
> >>> I disagree here. There is no need to make this info machine readable.
> >>> We want a clue about the optimizations which are all about creativity.
> >>> And we cannot make creativity of developers "machine readable".
> >>
> >> I am more concerned about the creativity in how developers describe optimizations.
> >> If there is no standardization of strings (or bits), the API will be challenging to use.
> >
> > No it won't be challenging because it will be just a string to print.
> 
> Well the challenge is getting everyone to use the same set of strings,
> such that what is returned by the API has common meaning.
> 
> I am fine with strings.
> So long as we have a method of encouraging folks to use a standard set were possible.
> 
> > The challenge is trying to fix the design characteristics in an API.
> 
> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start.
> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than
> we had.

Then, this one : http://patchwork.dpdk.org/patch/62368/ ?
Thomas Monjalon Nov. 4, 2019, 11:30 a.m. UTC | #53 
04/11/2019 11:03, Ray Kinsella:
> On 04/11/2019 09:54, Thomas Monjalon wrote:
> > 04/11/2019 10:49, Ray Kinsella:
> >> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>> 03/11/2019 21:35, Ray Kinsella:
> >>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>
> >>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>
> >>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>
> >>>>>>>>>>> [1]
> >>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>         uint64_t options;
> >>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>> };
> >>>>>>>>>>
> >>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>
> >>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>> variety of CPU architectures."
> >>>>>>>>
> >>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>
> >>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>> just simple bit test.
> >>>>>>>>>
> >>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>
> >>>>>>>> I have no word!
> >>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>
> >>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>> of the burst mode optimization.
> >>>>>>>>
> >>>>>>>> So you did not reply to my question:
> >>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>
> >>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>
> >>>>>> Again, please answer my question: why do you need it?
> >>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>> is used in the datapath design.
> >>>>>> There are so many options in a datapath design that it cannot be
> >>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>> criterias more important than others.
> >>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>
> >>>>> As I understand this is to let applications to give informed decision based on
> >>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>> application.
> >>>>>
> >>>>> And as previously replied, the main target of the API is to define the vector
> >>>>> path, not all optimizations, so the number is limited.
> >>>
> >>> No!
> >>> The name of this API is "burst mode information",
> >>> not "vector instructions used".
> >>> I think the main error is that in Intel PMDs,
> >>> each Rx/Tx function use different vector instructions.
> >>> So you generalize that knowing the vectors instructions
> >>> will give you a good information about the performance.
> >>> But this is generally wrong!
> >>> The right level of infos is much more complex.
> >>
> >> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
> >> with vector instructions. If there are other commonalities let's describe those also. 
> >>
> >> Vectorization was thought to be a good starting point - IMHO it is.
> >>
> >>>
> >>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>> causing this confusion, perhaps we can remove them.
> >>>>>
> >>>>> And if the requirement from the application is just informative, I would agree
> >>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>> is the main API to provide the information and
> >>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>> this information.
> >>>>>
> >>>>
> >>>> Well look we have a general deficit of information about what is happening under 
> >>>> the covers in DPDK. The end user may get wildly different performance characteristics 
> >>>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
> >>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>
> >>>> This can cause no end of head-scratching in consuming products, I have done some 
> >>>> of that head scratching myself, it is a usability nightmare. 
> >>>>
> >>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>
> >>>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
> >>>> information as possible, in as standard as format as possible. Otherwise DPDK 
> >>>> becomes arcane leaving the user running gdb to understand what is going on, as I 
> >>>> frequently do.
> >>>
> >>> I agree we must provide a clue to understand the performance result.
> >>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>> But his comment was ignored. 
> >>
> >> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >> It's very brittle and arcane way to provide information, if nothing else. 
> >>
> >>> You wanted an API, fine.
> >>> I am OK to have an API to request infos which are also in logs.
> >>
> >> I would point out that an API to query meta-data is common practice else where.
> >> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>
> >>>
> >>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
> >>>> ideal here.
> >>>
> >>> I disagree here. There is no need to make this info machine readable.
> >>> We want a clue about the optimizations which are all about creativity.
> >>> And we cannot make creativity of developers "machine readable".
> >>
> >> I am more concerned about the creativity in how developers describe optimizations. 
> >> If there is no standardization of strings (or bits), the API will be challenging to use. 
> > 
> > No it won't be challenging because it will be just a string to print.
> 
> Well the challenge is getting everyone to use the same set of strings, 
> such that what is returned by the API has common meaning. 
> 
> I am fine with strings.
> So long as we have a method of encouraging folks to use a standard set were possible.

I don't understand why you insist on standardizing.
Every drivers are different.
The routine names will have a sense only in the context of the driver.

> > The challenge is trying to fix the design characteristics in an API.
> 
> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start. 
> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had. 

The initial requirement is to describe what makes the performance
change from one routine to the other.
We don't want to describe the commonalities but the specific differences.
Please let's focus on the real requirement and build an API which really helps.
As said several times, a PMD-specific string would be a good API.
Ray Kinsella Nov. 4, 2019, 12:07 p.m. UTC | #54 
On 04/11/2019 11:30, Thomas Monjalon wrote:
> 04/11/2019 11:03, Ray Kinsella:
>> On 04/11/2019 09:54, Thomas Monjalon wrote:
>>> 04/11/2019 10:49, Ray Kinsella:
>>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
>>>>> 03/11/2019 21:35, Ray Kinsella:
>>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
>>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>>>>>>>> like AVX2.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not saying blocking the merge.
>>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>>>>>>>> +  uint64_t options;
>>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>>>>>>>> thing in the future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>>>>>>>> (options flags to string + dev_specific)
>>>>>>>>>>>>>
>>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>>>>>>>> interested in such a scheme.
>>>>>>>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> struct rte_eth_burst_mode {
>>>>>>>>>>>>>         uint64_t options;
>>>>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't see how we can have generic flags.
>>>>>>>>>>>> The flags which are proposed are just matching
>>>>>>>>>>>> the functions implemented in Intel PMDs.
>>>>>>>>>>>> And this is a complicate solution.
>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>>>
>>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>>>>>>>> variety of CPU architectures."
>>>>>>>>>>
>>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>>>>>>>> They just match some features of the Intel PMDs.
>>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>>>>>>>> You totally missed the point of generic burst mode description.
>>>>>>>>>>
>>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>>>>>>>> just simple bit test.
>>>>>>>>>>>
>>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>>>>>>>
>>>>>>>>>> I have no word!
>>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>>>>>>>> Or depending on which offloads are handled?
>>>>>>>>>>
>>>>>>>>>> Again, the instruction set used by the function is a small part
>>>>>>>>>> of the burst mode optimization.
>>>>>>>>>>
>>>>>>>>>> So you did not reply to my question:
>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>
>>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
>>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
>>>>>>>>
>>>>>>>> Again, please answer my question: why do you need it?
>>>>>>>> I think it is just informative, that's why a string should be enough.
>>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
>>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
>>>>>>>> for instance, or to know which offload is supported, or what hardware trick
>>>>>>>> is used in the datapath design.
>>>>>>>> There are so many options in a datapath design that it cannot be
>>>>>>>> represented with a bitmap. And it makes no sense to have some design
>>>>>>>> criterias more important than others.
>>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
>>>>>>>> a datapath design is more complicate than just using AVX instructions.
>>>>>>>
>>>>>>> As I understand this is to let applications to give informed decision based on
>>>>>>> what vectorization is used in the driver, currently this is not know by the
>>>>>>> application.
>>>>>>>
>>>>>>> And as previously replied, the main target of the API is to define the vector
>>>>>>> path, not all optimizations, so the number is limited.
>>>>>
>>>>> No!
>>>>> The name of this API is "burst mode information",
>>>>> not "vector instructions used".
>>>>> I think the main error is that in Intel PMDs,
>>>>> each Rx/Tx function use different vector instructions.
>>>>> So you generalize that knowing the vectors instructions
>>>>> will give you a good information about the performance.
>>>>> But this is generally wrong!
>>>>> The right level of infos is much more complex.
>>>>
>>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
>>>> with vector instructions. If there are other commonalities let's describe those also. 
>>>>
>>>> Vectorization was thought to be a good starting point - IMHO it is.
>>>>
>>>>>
>>>>>>> There are many optimization in the data path, I agree we may not represent all
>>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
>>>>>>> causing this confusion, perhaps we can remove them.
>>>>>>>
>>>>>>> And if the requirement from the application is just informative, I would agree
>>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
>>>>>>> is the main API to provide the information and
>>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
>>>>>>> this information.
>>>>>>>
>>>>>>
>>>>>> Well look we have a general deficit of information about what is happening under 
>>>>>> the covers in DPDK. The end user may get wildly different performance characteristics 
>>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
>>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
>>>>>>
>>>>>> This can cause no end of head-scratching in consuming products, I have done some 
>>>>>> of that head scratching myself, it is a usability nightmare. 
>>>>>>
>>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
>>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
>>>>>>
>>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
>>>>>> information as possible, in as standard as format as possible. Otherwise DPDK 
>>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I 
>>>>>> frequently do.
>>>>>
>>>>> I agree we must provide a clue to understand the performance result.
>>>>> As Stephen commented at the very beginning, a log is enough for such debug.
>>>>> But his comment was ignored. 
>>>>
>>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
>>>> It's very brittle and arcane way to provide information, if nothing else. 
>>>>
>>>>> You wanted an API, fine.
>>>>> I am OK to have an API to request infos which are also in logs.
>>>>
>>>> I would point out that an API to query meta-data is common practice else where.
>>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
>>>>
>>>>>
>>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
>>>>>> ideal here.
>>>>>
>>>>> I disagree here. There is no need to make this info machine readable.
>>>>> We want a clue about the optimizations which are all about creativity.
>>>>> And we cannot make creativity of developers "machine readable".
>>>>
>>>> I am more concerned about the creativity in how developers describe optimizations. 
>>>> If there is no standardization of strings (or bits), the API will be challenging to use. 
>>>
>>> No it won't be challenging because it will be just a string to print.
>>
>> Well the challenge is getting everyone to use the same set of strings, 
>> such that what is returned by the API has common meaning. 
>>
>> I am fine with strings.
>> So long as we have a method of encouraging folks to use a standard set were possible.
> 
> I don't understand why you insist on standardizing.
> Every drivers are different.
> The routine names will have a sense only in the context of the driver.

The more diversity in description, the more the user is reaching for documentation.
If the user is lucky enough that description has documentation.

We can argue about this indefinitely, instead of proposing a standard. :-)
The best way to this is to leave as the API as experimental for some period - as Haiyue suggests. 
And then review as the API drops experimental status, with a view to standardizing if possible?


> 
>>> The challenge is trying to fix the design characteristics in an API.
>>
>> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start. 
>> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had. 
> 
> The initial requirement is to describe what makes the performance
> change from one routine to the other.
> We don't want to describe the commonalities but the specific differences.
> Please let's focus on the real requirement and build an API which really helps.
> As said several times, a PMD-specific string would be a good API.
Thomas Monjalon Nov. 4, 2019, 1:09 p.m. UTC | #55 
04/11/2019 13:07, Ray Kinsella:
> 
> On 04/11/2019 11:30, Thomas Monjalon wrote:
> > 04/11/2019 11:03, Ray Kinsella:
> >> On 04/11/2019 09:54, Thomas Monjalon wrote:
> >>> 04/11/2019 10:49, Ray Kinsella:
> >>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>>>> 03/11/2019 21:35, Ray Kinsella:
> >>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1]
> >>>>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>>>         uint64_t options;
> >>>>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>>>> };
> >>>>>>>>>>>>
> >>>>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>
> >>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>>>> variety of CPU architectures."
> >>>>>>>>>>
> >>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>>>
> >>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>>>> just simple bit test.
> >>>>>>>>>>>
> >>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>>>
> >>>>>>>>>> I have no word!
> >>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>>>
> >>>>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>>>> of the burst mode optimization.
> >>>>>>>>>>
> >>>>>>>>>> So you did not reply to my question:
> >>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>
> >>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>>>
> >>>>>>>> Again, please answer my question: why do you need it?
> >>>>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>>>> is used in the datapath design.
> >>>>>>>> There are so many options in a datapath design that it cannot be
> >>>>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>>>> criterias more important than others.
> >>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>>>
> >>>>>>> As I understand this is to let applications to give informed decision based on
> >>>>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>>>> application.
> >>>>>>>
> >>>>>>> And as previously replied, the main target of the API is to define the vector
> >>>>>>> path, not all optimizations, so the number is limited.
> >>>>>
> >>>>> No!
> >>>>> The name of this API is "burst mode information",
> >>>>> not "vector instructions used".
> >>>>> I think the main error is that in Intel PMDs,
> >>>>> each Rx/Tx function use different vector instructions.
> >>>>> So you generalize that knowing the vectors instructions
> >>>>> will give you a good information about the performance.
> >>>>> But this is generally wrong!
> >>>>> The right level of infos is much more complex.
> >>>>
> >>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
> >>>> with vector instructions. If there are other commonalities let's describe those also. 
> >>>>
> >>>> Vectorization was thought to be a good starting point - IMHO it is.
> >>>>
> >>>>>
> >>>>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>>>> causing this confusion, perhaps we can remove them.
> >>>>>>>
> >>>>>>> And if the requirement from the application is just informative, I would agree
> >>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>>>> is the main API to provide the information and
> >>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>>>> this information.
> >>>>>>>
> >>>>>>
> >>>>>> Well look we have a general deficit of information about what is happening under 
> >>>>>> the covers in DPDK. The end user may get wildly different performance characteristics 
> >>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
> >>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>>>
> >>>>>> This can cause no end of head-scratching in consuming products, I have done some 
> >>>>>> of that head scratching myself, it is a usability nightmare. 
> >>>>>>
> >>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>>>
> >>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
> >>>>>> information as possible, in as standard as format as possible. Otherwise DPDK 
> >>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I 
> >>>>>> frequently do.
> >>>>>
> >>>>> I agree we must provide a clue to understand the performance result.
> >>>>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>>>> But his comment was ignored. 
> >>>>
> >>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >>>> It's very brittle and arcane way to provide information, if nothing else. 
> >>>>
> >>>>> You wanted an API, fine.
> >>>>> I am OK to have an API to request infos which are also in logs.
> >>>>
> >>>> I would point out that an API to query meta-data is common practice else where.
> >>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>>>
> >>>>>
> >>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
> >>>>>> ideal here.
> >>>>>
> >>>>> I disagree here. There is no need to make this info machine readable.
> >>>>> We want a clue about the optimizations which are all about creativity.
> >>>>> And we cannot make creativity of developers "machine readable".
> >>>>
> >>>> I am more concerned about the creativity in how developers describe optimizations. 
> >>>> If there is no standardization of strings (or bits), the API will be challenging to use. 
> >>>
> >>> No it won't be challenging because it will be just a string to print.
> >>
> >> Well the challenge is getting everyone to use the same set of strings, 
> >> such that what is returned by the API has common meaning. 
> >>
> >> I am fine with strings.
> >> So long as we have a method of encouraging folks to use a standard set were possible.
> > 
> > I don't understand why you insist on standardizing.
> > Every drivers are different.
> > The routine names will have a sense only in the context of the driver.
> 
> The more diversity in description, the more the user is reaching for documentation.
> If the user is lucky enough that description has documentation.

I would go even further:
The documentation will not explain each Rx/Tx routine.
The user can have some guess, but the main information is to see
that the routine changed from one run to the other, so he can expect
a change in the performance result.
And as a bonus, he can ask more explanation to the maintainers
by giving the routine name he got from the API.

> We can argue about this indefinitely, instead of proposing a standard. :-)
> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests. 
> And then review as the API drops experimental status, with a view to standardizing if possible?

Yes we can argue indefinitely.
My position is against standardizing this information.
(not even talking about the ABI breaks it could cause)

> >>> The challenge is trying to fix the design characteristics in an API.
> >>
> >> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start. 
> >> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had. 
> > 
> > The initial requirement is to describe what makes the performance
> > change from one routine to the other.
> > We don't want to describe the commonalities but the specific differences.
> > Please let's focus on the real requirement and build an API which really helps.
> > As said several times, a PMD-specific string would be a good API.
Ray Kinsella Nov. 4, 2019, 1:48 p.m. UTC | #56 
On 04/11/2019 13:09, Thomas Monjalon wrote:
> 04/11/2019 13:07, Ray Kinsella:
>>
>> On 04/11/2019 11:30, Thomas Monjalon wrote:
>>> 04/11/2019 11:03, Ray Kinsella:
>>>> On 04/11/2019 09:54, Thomas Monjalon wrote:
>>>>> 04/11/2019 10:49, Ray Kinsella:
>>>>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
>>>>>>> 03/11/2019 21:35, Ray Kinsella:
>>>>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
>>>>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
>>>>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
>>>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
>>>>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
>>>>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
>>>>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
>>>>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
>>>>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
>>>>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
>>>>>>>>>>>>>>>>>>> like AVX2.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
>>>>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
>>>>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
>>>>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not saying blocking the merge.
>>>>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
>>>>>>>>>>>>>>>> in this case. Same for Andrew I guess.
>>>>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
>>>>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
>>>>>>>>>>>>>>>>>>> +  uint64_t options;
>>>>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why a struct for an integer?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
>>>>>>>>>>>>>>>>> thing in the future.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
>>>>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
>>>>>>>>>>>>>>> and when a pass to the application, let common code make final string as
>>>>>>>>>>>>>>> (options flags to string + dev_specific)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
>>>>>>>>>>>>>>> interested in such a scheme.
>>>>>>>>>>>>>>> Generic flags will help at least to have some common code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> struct rte_eth_burst_mode {
>>>>>>>>>>>>>>>         uint64_t options;
>>>>>>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really don't see how we can have generic flags.
>>>>>>>>>>>>>> The flags which are proposed are just matching
>>>>>>>>>>>>>> the functions implemented in Intel PMDs.
>>>>>>>>>>>>>> And this is a complicate solution.
>>>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
>>>>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
>>>>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
>>>>>>>>>>>>> variety of CPU architectures."
>>>>>>>>>>>>
>>>>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
>>>>>>>>>>>> They just match some features of the Intel PMDs.
>>>>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
>>>>>>>>>>>> You totally missed the point of generic burst mode description.
>>>>>>>>>>>>
>>>>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
>>>>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
>>>>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
>>>>>>>>>>>>> just simple bit test.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
>>>>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
>>>>>>>>>>>>
>>>>>>>>>>>> I have no word!
>>>>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
>>>>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
>>>>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
>>>>>>>>>>>> Or depending on which offloads are handled?
>>>>>>>>>>>>
>>>>>>>>>>>> Again, the instruction set used by the function is a small part
>>>>>>>>>>>> of the burst mode optimization.
>>>>>>>>>>>>
>>>>>>>>>>>> So you did not reply to my question:
>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
>>>>>>>>>>>
>>>>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
>>>>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
>>>>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
>>>>>>>>>>
>>>>>>>>>> Again, please answer my question: why do you need it?
>>>>>>>>>> I think it is just informative, that's why a string should be enough.
>>>>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
>>>>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
>>>>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
>>>>>>>>>> for instance, or to know which offload is supported, or what hardware trick
>>>>>>>>>> is used in the datapath design.
>>>>>>>>>> There are so many options in a datapath design that it cannot be
>>>>>>>>>> represented with a bitmap. And it makes no sense to have some design
>>>>>>>>>> criterias more important than others.
>>>>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
>>>>>>>>>> a datapath design is more complicate than just using AVX instructions.
>>>>>>>>>
>>>>>>>>> As I understand this is to let applications to give informed decision based on
>>>>>>>>> what vectorization is used in the driver, currently this is not know by the
>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>> And as previously replied, the main target of the API is to define the vector
>>>>>>>>> path, not all optimizations, so the number is limited.
>>>>>>>
>>>>>>> No!
>>>>>>> The name of this API is "burst mode information",
>>>>>>> not "vector instructions used".
>>>>>>> I think the main error is that in Intel PMDs,
>>>>>>> each Rx/Tx function use different vector instructions.
>>>>>>> So you generalize that knowing the vectors instructions
>>>>>>> will give you a good information about the performance.
>>>>>>> But this is generally wrong!
>>>>>>> The right level of infos is much more complex.
>>>>>>
>>>>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization 
>>>>>> with vector instructions. If there are other commonalities let's describe those also. 
>>>>>>
>>>>>> Vectorization was thought to be a good starting point - IMHO it is.
>>>>>>
>>>>>>>
>>>>>>>>> There are many optimization in the data path, I agree we may not represent all
>>>>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
>>>>>>>>> causing this confusion, perhaps we can remove them.
>>>>>>>>>
>>>>>>>>> And if the requirement from the application is just informative, I would agree
>>>>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
>>>>>>>>> is the main API to provide the information and
>>>>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
>>>>>>>>> this information.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well look we have a general deficit of information about what is happening under 
>>>>>>>> the covers in DPDK. The end user may get wildly different performance characteristics 
>>>>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e 
>>>>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
>>>>>>>>
>>>>>>>> This can cause no end of head-scratching in consuming products, I have done some 
>>>>>>>> of that head scratching myself, it is a usability nightmare. 
>>>>>>>>
>>>>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
>>>>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
>>>>>>>>
>>>>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much 
>>>>>>>> information as possible, in as standard as format as possible. Otherwise DPDK 
>>>>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I 
>>>>>>>> frequently do.
>>>>>>>
>>>>>>> I agree we must provide a clue to understand the performance result.
>>>>>>> As Stephen commented at the very beginning, a log is enough for such debug.
>>>>>>> But his comment was ignored. 
>>>>>>
>>>>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
>>>>>> It's very brittle and arcane way to provide information, if nothing else. 
>>>>>>
>>>>>>> You wanted an API, fine.
>>>>>>> I am OK to have an API to request infos which are also in logs.
>>>>>>
>>>>>> I would point out that an API to query meta-data is common practice else where.
>>>>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
>>>>>>
>>>>>>>
>>>>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the 
>>>>>>>> ideal here.
>>>>>>>
>>>>>>> I disagree here. There is no need to make this info machine readable.
>>>>>>> We want a clue about the optimizations which are all about creativity.
>>>>>>> And we cannot make creativity of developers "machine readable".
>>>>>>
>>>>>> I am more concerned about the creativity in how developers describe optimizations. 
>>>>>> If there is no standardization of strings (or bits), the API will be challenging to use. 
>>>>>
>>>>> No it won't be challenging because it will be just a string to print.
>>>>
>>>> Well the challenge is getting everyone to use the same set of strings, 
>>>> such that what is returned by the API has common meaning. 
>>>>
>>>> I am fine with strings.
>>>> So long as we have a method of encouraging folks to use a standard set were possible.
>>>
>>> I don't understand why you insist on standardizing.
>>> Every drivers are different.
>>> The routine names will have a sense only in the context of the driver.
>>
>> The more diversity in description, the more the user is reaching for documentation.
>> If the user is lucky enough that description has documentation.
> 
> I would go even further:
> The documentation will not explain each Rx/Tx routine.
> The user can have some guess, but the main information is to see
> that the routine changed from one run to the other, so he can expect
> a change in the performance result.
> And as a bonus, he can ask more explanation to the maintainers
> by giving the routine name he got from the API.
> 
>> We can argue about this indefinitely, instead of proposing a standard. :-)
>> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests. 
>> And then review as the API drops experimental status, with a view to standardizing if possible?
> 
> Yes we can argue indefinitely.
> My position is against standardizing this information.
> (not even talking about the ABI breaks it could cause)

So here is my proposed work-around. 

We are probably to early to describe any commonalities beyond vectorization.
Vectorization is seen as too Intel specific.

Instead let's go with the PMD-specific strings for v20 ABI.
Let's review the PMD-specific strings that emerge during v20 + Experimental, 
and see if it possible to start to standardize for v21 ABI?

My position is that some degree of standardization is necessary here, for usability if no other reason.
I am happy to give it time for that to emerge instead of trying to dictate it. 

So go with PMD-specific strings, and review after 1 year to see if we can improve?

> 
>>>>> The challenge is trying to fix the design characteristics in an API.
>>>>
>>>> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid start. 
>>>> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better than we had. 
>>>
>>> The initial requirement is to describe what makes the performance
>>> change from one routine to the other.
>>> We don't want to describe the commonalities but the specific differences.
>>> Please let's focus on the real requirement and build an API which really helps.
>>> As said several times, a PMD-specific string would be a good API.
> 
> 
>
Wang, Haiyue Nov. 4, 2019, 2:17 p.m. UTC | #57 
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, November 4, 2019 21:49
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; 'Damjan Marion' <dmarion@me.com>; Wang,
> Haiyue <haiyue.wang@intel.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> viacheslavo@mellanox.com; stephen@networkplumber.org; arybchenko@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> 
> 
> On 04/11/2019 13:09, Thomas Monjalon wrote:
> > 04/11/2019 13:07, Ray Kinsella:
> >>
> >> On 04/11/2019 11:30, Thomas Monjalon wrote:
> >>> 04/11/2019 11:03, Ray Kinsella:
> >>>> On 04/11/2019 09:54, Thomas Monjalon wrote:
> >>>>> 04/11/2019 10:49, Ray Kinsella:
> >>>>>> On 03/11/2019 22:41, Thomas Monjalon wrote:
> >>>>>>> 03/11/2019 21:35, Ray Kinsella:
> >>>>>>>> On 29/10/2019 14:27, Ferruh Yigit wrote:
> >>>>>>>>> On 10/26/2019 5:23 PM, Thomas Monjalon wrote:
> >>>>>>>>>> 26/10/2019 11:23, Wang, Haiyue:
> >>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>> 26/10/2019 06:40, Wang, Haiyue:
> >>>>>>>>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>>>>>>>>>> 25/10/2019 18:02, Jerin Jacob:
> >>>>>>>>>>>>>>> On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >>>>>>>>>>>>>>>> 25/10/2019 16:08, Ferruh Yigit:
> >>>>>>>>>>>>>>>>> On 10/25/2019 10:36 AM, Thomas Monjalon wrote:
> >>>>>>>>>>>>>>>>>> 15/10/2019 09:51, Haiyue Wang:
> >>>>>>>>>>>>>>>>>>> Some PMDs have more than one RX/TX burst paths, add the ethdev API
> >>>>>>>>>>>>>>>>>>> that allows an application to retrieve the mode information about
> >>>>>>>>>>>>>>>>>>> Rx/Tx packet burst such as Scalar or Vector, and Vector technology
> >>>>>>>>>>>>>>>>>>> like AVX2.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed.
> >>>>>>>>>>>>>>>>>> Ferruh, I would expect to be Cc'ed and/or get a notification before merging.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It has been discussed in the mail list and went through multiple discussions,
> >>>>>>>>>>>>>>>>> patch is out since the August, +1 to cc all maintainers I missed that part,
> >>>>>>>>>>>>>>>>> but when the patch is reviewed and there is no objection, why block the merge?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm not saying blocking the merge.
> >>>>>>>>>>>>>>>> My bad is that I missed the patch and I am asking for help with a notification
> >>>>>>>>>>>>>>>> in this case. Same for Andrew I guess.
> >>>>>>>>>>>>>>>> Note: it is merged in master and I am looking to improve this feature.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>> + * Ethernet device RX/TX queue packet burst mode information structure.
> >>>>>>>>>>>>>>>>>>> + * Used to retrieve information about packet burst mode setting.
> >>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>> +struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>>>>>> +  uint64_t options;
> >>>>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Why a struct for an integer?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Again by a request from me, to not need to break the API if we need to add more
> >>>>>>>>>>>>>>>>> thing in the future.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would replace it with a string. This is the most flexible API.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> IMO, Probably, best of both worlds make a good option here,
> >>>>>>>>>>>>>>> as Haiyue suggested if we have an additional dev_specific[1] in structure.
> >>>>>>>>>>>>>>> and when a pass to the application, let common code make final string as
> >>>>>>>>>>>>>>> (options flags to string + dev_specific)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> options flag can be zero if PMD does not have any generic flags nor
> >>>>>>>>>>>>>>> interested in such a scheme.
> >>>>>>>>>>>>>>> Generic flags will help at least to have some common code.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>> struct rte_eth_burst_mode {
> >>>>>>>>>>>>>>>         uint64_t options;
> >>>>>>>>>>>>>>>         char dev_specific[128]; /* PMD has specific burst mode information */
> >>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I really don't see how we can have generic flags.
> >>>>>>>>>>>>>> The flags which are proposed are just matching
> >>>>>>>>>>>>>> the functions implemented in Intel PMDs.
> >>>>>>>>>>>>>> And this is a complicate solution.
> >>>>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Intel PMDs use the *generic* methods like x86 SSE, AVX2, ARM NEON, PPC ALTIVEC,
> >>>>>>>>>>>>> 'dev->data->scattered_rx' etc for the target : "DPDK is the Data Plane Development Kit
> >>>>>>>>>>>>> that consists of libraries to accelerate packet processing workloads running on a wide
> >>>>>>>>>>>>> variety of CPU architectures."
> >>>>>>>>>>>>
> >>>>>>>>>>>> How RTE_ETH_BURST_SCATTERED and RTE_ETH_BURST_BULK_ALLOC are generic?
> >>>>>>>>>>>> They just match some features of the Intel PMDs.
> >>>>>>>>>>>> Why not exposing other optimizations of the Rx/Tx implementations?
> >>>>>>>>>>>> You totally missed the point of generic burst mode description.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> If understand these new experimental APIs from above, then bit options is the best,
> >>>>>>>>>>>>> and we didn't invent new words to describe them, just from the CPU & other *generic*
> >>>>>>>>>>>>> technology. And the application can loop to check which kind of burst is running by
> >>>>>>>>>>>>> just simple bit test.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If PMDs missed these, they can update them in future roadmaps to enhance their PMDs,
> >>>>>>>>>>>>> like MLX5 supports ARM NEON, x86 SSE.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have no word!
> >>>>>>>>>>>> You really think other PMDs should learn from Intel how to "enhance" their PMD?
> >>>>>>>>>>>> You talk about mlx5, did you look at its code? Did you see the burst modes
> >>>>>>>>>>>> depending on which specific hardware path is used (MPRQ, EMPW, inline)?
> >>>>>>>>>>>> Or depending on which offloads are handled?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Again, the instruction set used by the function is a small part
> >>>>>>>>>>>> of the burst mode optimization.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So you did not reply to my question:
> >>>>>>>>>>>> Why not just returning a name for the selected Rx/Tx mode?
> >>>>>>>>>>>
> >>>>>>>>>>> In fact, RFC v1/v2 returns the *name*, but the *name* is hard for
> >>>>>>>>>>> application to do further processing, strcmp, strstr ? Not so nice
> >>>>>>>>>>> for C code, and it is not so standard, So switch it to bit definition.
> >>>>>>>>>>
> >>>>>>>>>> Again, please answer my question: why do you need it?
> >>>>>>>>>> I think it is just informative, that's why a string should be enough.
> >>>>>>>>>> I am clearly against the bitmap because it is way too much restrictive.
> >>>>>>>>>> I disagree that knowing it is using AVX2 or AVX512 is so interesting.
> >>>>>>>>>> What you would like to know is whether it is processing packets 4 by 4,
> >>>>>>>>>> for instance, or to know which offload is supported, or what hardware trick
> >>>>>>>>>> is used in the datapath design.
> >>>>>>>>>> There are so many options in a datapath design that it cannot be
> >>>>>>>>>> represented with a bitmap. And it makes no sense to have some design
> >>>>>>>>>> criterias more important than others.
> >>>>>>>>>> I Cc an Intel architect (Edwin) who could explain you how much
> >>>>>>>>>> a datapath design is more complicate than just using AVX instructions.
> >>>>>>>>>
> >>>>>>>>> As I understand this is to let applications to give informed decision based on
> >>>>>>>>> what vectorization is used in the driver, currently this is not know by the
> >>>>>>>>> application.
> >>>>>>>>>
> >>>>>>>>> And as previously replied, the main target of the API is to define the vector
> >>>>>>>>> path, not all optimizations, so the number is limited.
> >>>>>>>
> >>>>>>> No!
> >>>>>>> The name of this API is "burst mode information",
> >>>>>>> not "vector instructions used".
> >>>>>>> I think the main error is that in Intel PMDs,
> >>>>>>> each Rx/Tx function use different vector instructions.
> >>>>>>> So you generalize that knowing the vectors instructions
> >>>>>>> will give you a good information about the performance.
> >>>>>>> But this is generally wrong!
> >>>>>>> The right level of infos is much more complex.
> >>>>>>
> >>>>>> I don't think anyone was suggesting limiting it to purely describing PMD optimization
> >>>>>> with vector instructions. If there are other commonalities let's describe those also.
> >>>>>>
> >>>>>> Vectorization was thought to be a good starting point - IMHO it is.
> >>>>>>
> >>>>>>>
> >>>>>>>>> There are many optimization in the data path, I agree we may not represent all
> >>>>>>>>> of them, and agreed existing enum having "RTE_ETH_BURST_BULK_ALLOC" and similar
> >>>>>>>>> causing this confusion, perhaps we can remove them.
> >>>>>>>>>
> >>>>>>>>> And if the requirement from the application is just informative, I would agree
> >>>>>>>>> that free text string will be better, right now 'rte_eth_rx/tx_burst_mode_get()'
> >>>>>>>>> is the main API to provide the information and
> >>>>>>>>> 'rte_eth_burst_mode_option_name()' is a helper for application/driver to log
> >>>>>>>>> this information.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Well look we have a general deficit of information about what is happening under
> >>>>>>>> the covers in DPDK. The end user may get wildly different performance characteristics
> >>>>>>>> based on the DPDK configuration. Simple example is using flow director causes the i40e
> >>>>>>>> PMD to switch to using a scalar code path, and performance may as much as half.
> >>>>>>>>
> >>>>>>>> This can cause no end of head-scratching in consuming products, I have done some
> >>>>>>>> of that head scratching myself, it is a usability nightmare.
> >>>>>>>>
> >>>>>>>> FD.io VPP tries to work around this by mining the call stack, to give the user _some_
> >>>>>>>> kind of information about what is happening. These kind of heroics should not be necessary.
> >>>>>>>>
> >>>>>>>> For exactly the same reasons as telemetry, we should be trying to give the users as much
> >>>>>>>> information as possible, in as standard as format as possible. Otherwise DPDK
> >>>>>>>> becomes arcane leaving the user running gdb to understand what is going on, as I
> >>>>>>>> frequently do.
> >>>>>>>
> >>>>>>> I agree we must provide a clue to understand the performance result.
> >>>>>>> As Stephen commented at the very beginning, a log is enough for such debug.
> >>>>>>> But his comment was ignored.
> >>>>>>
> >>>>>> Do we expect applications built on DPDK to have to grep it's log to make such discoveries?
> >>>>>> It's very brittle and arcane way to provide information, if nothing else.
> >>>>>>
> >>>>>>> You wanted an API, fine.
> >>>>>>> I am OK to have an API to request infos which are also in logs.
> >>>>>>
> >>>>>> I would point out that an API to query meta-data is common practice else where.
> >>>>>> GStreamer GstCaps and Linux Sysfs are the closest example I can think of.
> >>>>>>
> >>>>>>>
> >>>>>>>> Finally, again for the same reasons as telemetry, I would say that machine readable is the
> >>>>>>>> ideal here.
> >>>>>>>
> >>>>>>> I disagree here. There is no need to make this info machine readable.
> >>>>>>> We want a clue about the optimizations which are all about creativity.
> >>>>>>> And we cannot make creativity of developers "machine readable".
> >>>>>>
> >>>>>> I am more concerned about the creativity in how developers describe optimizations.
> >>>>>> If there is no standardization of strings (or bits), the API will be challenging to use.
> >>>>>
> >>>>> No it won't be challenging because it will be just a string to print.
> >>>>
> >>>> Well the challenge is getting everyone to use the same set of strings,
> >>>> such that what is returned by the API has common meaning.
> >>>>
> >>>> I am fine with strings.
> >>>> So long as we have a method of encouraging folks to use a standard set were possible.
> >>>
> >>> I don't understand why you insist on standardizing.
> >>> Every drivers are different.
> >>> The routine names will have a sense only in the context of the driver.
> >>
> >> The more diversity in description, the more the user is reaching for documentation.
> >> If the user is lucky enough that description has documentation.
> >
> > I would go even further:
> > The documentation will not explain each Rx/Tx routine.
> > The user can have some guess, but the main information is to see
> > that the routine changed from one run to the other, so he can expect
> > a change in the performance result.
> > And as a bonus, he can ask more explanation to the maintainers
> > by giving the routine name he got from the API.
> >
> >> We can argue about this indefinitely, instead of proposing a standard. :-)
> >> The best way to this is to leave as the API as experimental for some period - as Haiyue suggests.
> >> And then review as the API drops experimental status, with a view to standardizing if possible?
> >
> > Yes we can argue indefinitely.
> > My position is against standardizing this information.
> > (not even talking about the ABI breaks it could cause)
> 
> So here is my proposed work-around.
> 
> We are probably to early to describe any commonalities beyond vectorization.
> Vectorization is seen as too Intel specific.
> 
> Instead let's go with the PMD-specific strings for v20 ABI.
> Let's review the PMD-specific strings that emerge during v20 + Experimental,
> and see if it possible to start to standardize for v21 ABI?
> 
> My position is that some degree of standardization is necessary here, for usability if no other reason.
> I am happy to give it time for that to emerge instead of trying to dictate it.
> 
> So go with PMD-specific strings, and review after 1 year to see if we can improve?
> 

Hi Experts,

Please give feedback on new patch. :-)

http://patchwork.dpdk.org/patch/62368/

struct rte_eth_burst_mode {
	uint64_t flags; /**< The ORed values of RTE_ETH_BURST_FLAG_xxx */

#define RTE_ETH_BURST_MODE_INFO_SIZE 1024 /**< Maximum size for information */
	char info[RTE_ETH_BURST_MODE_INFO_SIZE]; /**< burst mode information */
};

If most of PMDs want to follow some rule to format string, maybe new flag can be
defined like: RTE_ETH_BURST_FLAG_FMT_BY_XXX, then the 'info' has some kind of the
same format. And the old application can still just *display* it. New application
can parse it by the known format as indicated by RTE_ETH_BURST_FLAG_FMT_BY_XXX.

Buy in this design ?


> >
> >>>>> The challenge is trying to fix the design characteristics in an API.
> >>>>
> >>>> I thought Haiyue's patch with a fair degree of input from Ferruh and others is a pretty solid
> start.
> >>>> Let's describe those commonalities that _do_ exist today - it may not be enough, but it's better
> than we had.
> >>>
> >>> The initial requirement is to describe what makes the performance
> >>> change from one routine to the other.
> >>> We don't want to describe the commonalities but the specific differences.
> >>> Please let's focus on the real requirement and build an API which really helps.
> >>> As said several times, a PMD-specific string would be a good API.
> >
> >
> >
diff mbox series

Patch

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c4e128d2f..d96696801 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -871,6 +871,17 @@  Supports Tx queue setup after device started.
 * **[provides] rte_eth_dev_info**: ``dev_capa:RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP``.
 * **[related]  API**: ``rte_eth_dev_info_get()``.
 
+.. _nic_features_burst_mode_info:
+
+Burst mode info
+---------------
+
+Supports to get Rx/Tx packet burst mode information.
+
+* **[implements] eth_dev_ops**: ``rx_burst_mode_get``, ``tx_burst_mode_get``.
+* **[related] API**: ``rte_eth_rx_burst_mode_get()``, ``rte_eth_tx_burst_mode_get()``,
+  ``rte_eth_burst_mode_option_name()``.
+
 .. _nic_features_other:
 
 Other dev ops not represented by a Feature
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index dfbdf084e..91ec61901 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -19,6 +19,7 @@  Free Tx mbuf on demand =
 Queue start/stop     =
 Runtime Rx queue setup =
 Runtime Tx queue setup =
+Burst mode info      =
 MTU update           =
 Jumbo frame          =
 Scattered Rx         =
diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst
index a63c8af15..8634a7b81 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -83,6 +83,15 @@  New Features
 
   Added support for the ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
 
+* **Added RX/TX packet burst mode get API.**
+
+  Added two new functions ``rte_eth_rx_burst_mode_get`` and
+  ``rte_eth_tx_burst_mode_get`` that allow an application
+  to retrieve the mode information about RX/TX packet burst
+  such as Scalar or Vector, and Vector technology like AVX2.
+  Another new function ``rte_eth_burst_mode_option_name`` is
+  provided for burst mode options stringification.
+
 * **Updated the Intel ice driver.**
 
   Updated the Intel ice driver with new features and improvements, including:
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 7caaa0be3..750bc9d02 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -166,6 +166,25 @@  static const struct {
 
 #undef RTE_TX_OFFLOAD_BIT2STR
 
+static const struct {
+	uint64_t option;
+	const char *name;
+} rte_burst_option_names[] = {
+	{ RTE_ETH_BURST_SCALAR, "Scalar" },
+	{ RTE_ETH_BURST_VECTOR, "Vector" },
+
+	{ RTE_ETH_BURST_ALTIVEC, "AltiVec" },
+	{ RTE_ETH_BURST_NEON, "Neon" },
+	{ RTE_ETH_BURST_SSE, "SSE" },
+	{ RTE_ETH_BURST_AVX2, "AVX2" },
+	{ RTE_ETH_BURST_AVX512, "AVX512" },
+
+	{ RTE_ETH_BURST_SCATTERED, "Scattered" },
+	{ RTE_ETH_BURST_BULK_ALLOC, "Bulk Alloc" },
+	{ RTE_ETH_BURST_SIMPLE, "Simple" },
+	{ RTE_ETH_BURST_PER_QUEUE, "Per Queue" },
+};
+
 /**
  * The user application callback description.
  *
@@ -4210,6 +4229,70 @@  rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
 	return 0;
 }
 
+int
+rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
+			  struct rte_eth_burst_mode *mode)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+	if (mode == NULL)
+		return -EINVAL;
+
+	dev = &rte_eth_devices[port_id];
+
+	if (queue_id >= dev->data->nb_rx_queues) {
+		RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
+		return -EINVAL;
+	}
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_burst_mode_get, -ENOTSUP);
+	memset(mode, 0, sizeof(*mode));
+	return eth_err(port_id,
+		       dev->dev_ops->rx_burst_mode_get(dev, queue_id, mode));
+}
+
+int
+rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
+			  struct rte_eth_burst_mode *mode)
+{
+	struct rte_eth_dev *dev;
+
+	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+	if (mode == NULL)
+		return -EINVAL;
+
+	dev = &rte_eth_devices[port_id];
+
+	if (queue_id >= dev->data->nb_tx_queues) {
+		RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
+		return -EINVAL;
+	}
+
+	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_burst_mode_get, -ENOTSUP);
+	memset(mode, 0, sizeof(*mode));
+	return eth_err(port_id,
+		       dev->dev_ops->tx_burst_mode_get(dev, queue_id, mode));
+}
+
+const char *
+rte_eth_burst_mode_option_name(uint64_t option)
+{
+	const char *name = "";
+	unsigned int i;
+
+	for (i = 0; i < RTE_DIM(rte_burst_option_names); ++i) {
+		if (option == rte_burst_option_names[i].option) {
+			name = rte_burst_option_names[i].name;
+			break;
+		}
+	}
+
+	return name;
+}
+
 int
 rte_eth_dev_set_mc_addr_list(uint16_t port_id,
 			     struct rte_ether_addr *mc_addr_set,
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index c26abe23a..83b08ee4d 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1214,6 +1214,32 @@  struct rte_eth_txq_info {
 	uint16_t nb_desc;           /**< configured number of TXDs. */
 } __rte_cache_min_aligned;
 
+enum rte_eth_burst_mode_option {
+	RTE_ETH_BURST_SCALAR = (1 << 0),
+	RTE_ETH_BURST_VECTOR = (1 << 1),
+
+	/**< bits[15:2] are reserved for each vector type */
+	RTE_ETH_BURST_ALTIVEC = (1 << 2),
+	RTE_ETH_BURST_NEON = (1 << 3),
+	RTE_ETH_BURST_SSE = (1 << 4),
+	RTE_ETH_BURST_AVX2 = (1 << 5),
+	RTE_ETH_BURST_AVX512 = (1 << 6),
+
+	RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */
+	RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */
+	RTE_ETH_BURST_SIMPLE = (1 << 18),
+
+	RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */
+};
+
+/**
+ * Ethernet device RX/TX queue packet burst mode information structure.
+ * Used to retrieve information about packet burst mode setting.
+ */
+struct rte_eth_burst_mode {
+	uint64_t options;
+};
+
 /** Maximum name length for extended statistics counters */
 #define RTE_ETH_XSTATS_NAME_SIZE 64
 
@@ -3602,6 +3628,62 @@  int rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id,
 int rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
 	struct rte_eth_txq_info *qinfo);
 
+/**
+ * Retrieve information about the Rx packet burst mode.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param queue_id
+ *   The Rx queue on the Ethernet device for which information
+ *   will be retrieved.
+ * @param mode
+ *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
+ *   with the information of the packet burst mode.
+ *
+ * @return
+ *   - 0: Success
+ *   - -ENOTSUP: routine is not supported by the device PMD.
+ *   - -EINVAL:  The port_id or the queue_id is out of range.
+ */
+__rte_experimental
+int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
+	struct rte_eth_burst_mode *mode);
+
+/**
+ * Retrieve information about the Tx packet burst mode.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param queue_id
+ *   The Tx queue on the Ethernet device for which information
+ *   will be retrieved.
+ * @param mode
+ *   A pointer to a structure of type *rte_eth_burst_mode* to be filled
+ *   with the information of the packet burst mode.
+ *
+ * @return
+ *   - 0: Success
+ *   - -ENOTSUP: routine is not supported by the device PMD.
+ *   - -EINVAL:  The port_id or the queue_id is out of range.
+ */
+__rte_experimental
+int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
+	struct rte_eth_burst_mode *mode);
+
+/**
+ * Retrieve name about burst mode option.
+ *
+ * @param mode
+ *   The burst mode option of type *rte_eth_burst_mode_option*.
+ *
+ * @return
+ *   - "": Not found
+ *   - "xxx": name of the mode option.
+ */
+__rte_experimental
+const char *
+rte_eth_burst_mode_option_name(uint64_t option);
+
 /**
  * Retrieve device registers and register attributes (number of registers and
  * register size)
diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
index dcb5ae651..392aea8e6 100644
--- a/lib/librte_ethdev/rte_ethdev_core.h
+++ b/lib/librte_ethdev/rte_ethdev_core.h
@@ -294,6 +294,9 @@  typedef void (*eth_rxq_info_get_t)(struct rte_eth_dev *dev,
 typedef void (*eth_txq_info_get_t)(struct rte_eth_dev *dev,
 	uint16_t tx_queue_id, struct rte_eth_txq_info *qinfo);
 
+typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev,
+	uint16_t queue_id, struct rte_eth_burst_mode *mode);
+
 typedef int (*mtu_set_t)(struct rte_eth_dev *dev, uint16_t mtu);
 /**< @internal Set MTU. */
 
@@ -542,6 +545,8 @@  struct eth_dev_ops {
 	eth_dev_infos_get_t        dev_infos_get; /**< Get device info. */
 	eth_rxq_info_get_t         rxq_info_get; /**< retrieve RX queue information. */
 	eth_txq_info_get_t         txq_info_get; /**< retrieve TX queue information. */
+	eth_burst_mode_get_t       rx_burst_mode_get; /**< Get RX burst mode */
+	eth_burst_mode_get_t       tx_burst_mode_get; /**< Get TX burst mode */
 	eth_fw_version_get_t       fw_version_get; /**< Get firmware version. */
 	eth_dev_supported_ptypes_get_t dev_supported_ptypes_get;
 	/**< Get packet types supported and identified by device. */
diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
index 6df42a47b..e59d51648 100644
--- a/lib/librte_ethdev/rte_ethdev_version.map
+++ b/lib/librte_ethdev/rte_ethdev_version.map
@@ -283,4 +283,9 @@  EXPERIMENTAL {
 
 	# added in 19.08
 	rte_eth_read_clock;
+
+	# added in 19.11
+	rte_eth_rx_burst_mode_get;
+	rte_eth_tx_burst_mode_get;
+	rte_eth_burst_mode_option_name;
 };