[dpdk-dev] [PATCH] doc: add new field to rxq info struct

[dpdk-dev] [PATCH] doc: add new field to rxq info struct

[Chengchang Tang]

Struct rte_eth_rxq_info will be modified to include a new field, indicating
the size of each buffer that could be used for hw to receive packets. Add
this field to rte_eth_rxq_info to expose relevant information to upper
layer users/application.

For more details:
https://mails.dpdk.org/archives/dev/2020-July/176135.html

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
---
 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ea4cfa7..f931091 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -110,6 +110,15 @@ Deprecation Notices
   break the ABI checks, that is why change is planned for 20.11.
   The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.

+* ethdev: A new field named rx_buf_size will be added to the public data
+  structure ``rte_eth_rxq_info`` to indicate the buffer size used in receiving
+  pkts for hw. when receive packets, hw DMA won't exceed this size. And it will
+  affect the number of fragments in receiving packets when scatter is enabled.
+  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
+  upper layer user/application.
+  This change is planed for 20.11. For more details:
+  https://mails.dpdk.org/archives/dev/2020-July/176135.html
+
 * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
   ABI stable in the v19.11 release. The TM maintainer and other contributors have
   agreed to keep the TM APIs as experimental in expectation of additional spec
--
2.7.4

Re: [dpdk-dev] [PATCH] doc: add new field to rxq info struct

[Andrew Rybchenko]

On 8/5/20 12:24 PM, Chengchang Tang wrote:
> Struct rte_eth_rxq_info will be modified to include a new field, indicating
> the size of each buffer that could be used for hw to receive packets. Add
> this field to rte_eth_rxq_info to expose relevant information to upper
> layer users/application.
> 
> For more details:
> https://mails.dpdk.org/archives/dev/2020-July/176135.html
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>

Few nits below

Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>

> ---
>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7..f931091 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -110,6 +110,15 @@ Deprecation Notices
>    break the ABI checks, that is why change is planned for 20.11.
>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
> 
> +* ethdev: A new field named rx_buf_size will be added to the public data

I'd not name the field here. It is out-of-scope of the
deprecation notice. Field name may change on its way.

> +  structure ``rte_eth_rxq_info`` to indicate the buffer size used in receiving
> +  pkts for hw. when receive packets, hw DMA won't exceed this size. And it will

pkts -> packets
hw -> HW (2 cases)
when -> When

> +  affect the number of fragments in receiving packets when scatter is enabled.
> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
> +  upper layer user/application.
> +  This change is planed for 20.11. For more details:
> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html
> +
>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
>    agreed to keep the TM APIs as experimental in expectation of additional spec
> --
> 2.7.4
> 

[dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Chengchang Tang]

Struct rte_eth_rxq_info will be modified to include a new field, indicating
the size of each buffer that could be used for hw to receive packets. Add
this field to rte_eth_rxq_info to expose relevant information to upper
layer users/application.

For more details:
https://mails.dpdk.org/archives/dev/2020-July/176135.html

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
 v2:
 - Remove field name.
 - Fix some spelling mistakes.
---
 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ea4cfa7..f08b5f9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -110,6 +110,15 @@ Deprecation Notices
   break the ABI checks, that is why change is planned for 20.11.
   The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.

+* ethdev: A new field will be added to the public data structure
+  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
+  for HW. When receive packets, HW DMA won't exceed this size. And it will
+  affect the number of fragments in receiving packets when scatter is enabled.
+  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
+  upper layer user/application.
+  This change is planned for 20.11. For more details:
+  https://mails.dpdk.org/archives/dev/2020-July/176135.html
+
 * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
   ABI stable in the v19.11 release. The TM maintainer and other contributors have
   agreed to keep the TM APIs as experimental in expectation of additional spec
--
2.7.4

[dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Chengchang Tang]

Struct rte_eth_rxq_info will be modified to include a new field, indicating
the size of each buffer that could be used for hw to receive packets. Add
this field to rte_eth_rxq_info to expose relevant information to upper
layer users/application.

For more details:
https://mails.dpdk.org/archives/dev/2020-July/176135.html

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ea4cfa7..f08b5f9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -110,6 +110,15 @@ Deprecation Notices
   break the ABI checks, that is why change is planned for 20.11.
   The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
 
+* ethdev: A new field will be added to the public data structure
+  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
+  for HW. When receive packets, HW DMA won't exceed this size. And it will
+  affect the number of fragments in receiving packets when scatter is enabled.
+  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
+  upper layer user/application.
+  This change is planned for 20.11. For more details:
+  https://mails.dpdk.org/archives/dev/2020-July/176135.html
+
 * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
   ABI stable in the v19.11 release. The TM maintainer and other contributors have
   agreed to keep the TM APIs as experimental in expectation of additional spec
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Slava Ovsiienko]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Chengchang Tang
> Sent: Thursday, August 6, 2020 7:01
> To: dev@dpdk.org
> Cc: linuxarm@huawei.com; Thomas Monjalon <thomas@monjalon.net>;
> ferruh.yigit@intel.com; arybchenko@solarflare.com;
> stephen@networkplumber.org
> Subject: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct
> 
> Struct rte_eth_rxq_info will be modified to include a new field, indicating the
> size of each buffer that could be used for hw to receive packets. Add this
> field to rte_eth_rxq_info to expose relevant information to upper layer
> users/application.
> 
> For more details:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.
> dpdk.org%2Farchives%2Fdev%2F2020-
> July%2F176135.html&amp;data=02%7C01%7Cviacheslavo%40mellanox.com
> %7Cdb0d8bcc221145a4a67508d839bd9f14%7Ca652971c7d2e4d9ba6a4d149
> 256f461b%7C0%7C0%7C637322833881598698&amp;sdata=W2G3iEdepIjSlp
> Wq4296k7cmXV1RhMnfl88TAjivWLc%3D&amp;reserved=0
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
>  v2:
>  - Remove field name.
>  - Fix some spelling mistakes.
> ---
>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7..f08b5f9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -110,6 +110,15 @@ Deprecation Notices
>    break the ABI checks, that is why change is planned for 20.11.
>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
> 
> +* ethdev: A new field will be added to the public data structure
> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving
> +packets
> +  for HW. When receive packets, HW DMA won't exceed this size. And it
> +will
> +  affect the number of fragments in receiving packets when scatter is
> enabled.
> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant
> +information to
> +  upper layer user/application.
> +  This change is planned for 20.11. For more details:
> +
> +https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> s
> +.dpdk.org%2Farchives%2Fdev%2F2020-
> July%2F176135.html&amp;data=02%7C01%7
> +Cviacheslavo%40mellanox.com%7Cdb0d8bcc221145a4a67508d839bd9f14
> %7Ca65297
> +1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637322833881598698&amp
> ;sdata=W2G3i
> +EdepIjSlpWq4296k7cmXV1RhMnfl88TAjivWLc%3D&amp;reserved=0
> +
>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly
> made
>    ABI stable in the v19.11 release. The TM maintainer and other contributors
> have
>    agreed to keep the TM APIs as experimental in expectation of additional
> spec
> --
> 2.7.4
We are going to introduce the more flexible format to descript the rx buffers
with multiple segment lengths/pools. It might be worth to consider extending this
info structure single field to array. I suppose it is the subject for further discussion (on RFC).

Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Ferruh Yigit]

On 8/6/2020 5:00 AM, Chengchang Tang wrote:
> Struct rte_eth_rxq_info will be modified to include a new field, indicating
> the size of each buffer that could be used for hw to receive packets. Add
> this field to rte_eth_rxq_info to expose relevant information to upper
> layer users/application.
> 
> For more details:
> https://mails.dpdk.org/archives/dev/2020-July/176135.html
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7..f08b5f9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -110,6 +110,15 @@ Deprecation Notices
>    break the ABI checks, that is why change is planned for 20.11.
>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
>  
> +* ethdev: A new field will be added to the public data structure
> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
> +  for HW. When receive packets, HW DMA won't exceed this size.

Overall +1 to provide this information.

This field is only to report back the PMD configured Rx buffer size, it won't
affect the configuration step, do you think should we highlight this?

Also will this field be optional or mandatory, this matters for the scope of the
work for 20.11. I think the intention is to provide an optional field, what do
you think to documenting that it is optional?

> And it will
> +  affect the number of fragments in receiving packets when scatter is enabled.

Is this detail required in the deprecation notice? I see it is relevant but
the configured Rx buffer size affects the number of the fragments, but reporting
this value does not.
Do you want to mention above as motivation to have the field? If so I don't
expect application to calculate the number of the fragments using this value.
I am for dropping above sentences if I am not missing anything.

> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
> +  upper layer user/application.

And not sure above sentences says anything new, looks like duplication to me.

> +  This change is planned for 20.11. For more details:
> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html
> +
>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
>    agreed to keep the TM APIs as experimental in expectation of additional spec
> 

Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Chengchang Tang]

On 2020/8/6 23:25, Ferruh Yigit wrote:
> On 8/6/2020 5:00 AM, Chengchang Tang wrote:
>> Struct rte_eth_rxq_info will be modified to include a new field, indicating
>> the size of each buffer that could be used for hw to receive packets. Add
>> this field to rte_eth_rxq_info to expose relevant information to upper
>> layer users/application.
>>
>> For more details:
>> https://mails.dpdk.org/archives/dev/2020-July/176135.html
>>
>> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> ---
>>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>> index ea4cfa7..f08b5f9 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -110,6 +110,15 @@ Deprecation Notices
>>    break the ABI checks, that is why change is planned for 20.11.
>>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
>>  
>> +* ethdev: A new field will be added to the public data structure
>> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
>> +  for HW. When receive packets, HW DMA won't exceed this size.
> 
> Overall +1 to provide this information.
> 
> This field is only to report back the PMD configured Rx buffer size, it won't
> affect the configuration step, do you think should we highlight this?
I think it is not necessary because this structure is designed to report PMD
configuration. And it is only used in rte_eth_rx_queue_info_get.
> 
> Also will this field be optional or mandatory, this matters for the scope of the
> work for 20.11. I think the intention is to provide an optional field, what do
> you think to documenting that it is optional?
Yes, it is optional. I will highlight this in v3.
> 
>> And it will
>> +  affect the number of fragments in receiving packets when scatter is enabled.
> 
> Is this detail required in the deprecation notice? I see it is relevant but
> the configured Rx buffer size affects the number of the fragments, but reporting
> this value does not.
> Do you want to mention above as motivation to have the field? If so I don't
> expect application to calculate the number of the fragments using this value.
> I am for dropping above sentences if I am not missing anything.
Thank you for this advice. I am not sure what information should be reflected in
a deprecation notice. I seem to have added some redundant and inappropriate stuff.
I will drop these sentences in v3.
> 
>> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
>> +  upper layer user/application.
> 
> And not sure above sentences says anything new, looks like duplication to me.
> 
>> +  This change is planned for 20.11. For more details:
>> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html
>> +
>>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
>>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
>>    agreed to keep the TM APIs as experimental in expectation of additional spec
>>
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Chengchang Tang]

On 2020/8/6 20:50, Slava Ovsiienko wrote:
>> -----Original Message-----
>> From: dev <dev-bounces@dpdk.org> On Behalf Of Chengchang Tang
>> Sent: Thursday, August 6, 2020 7:01
>> To: dev@dpdk.org
>> Cc: linuxarm@huawei.com; Thomas Monjalon <thomas@monjalon.net>;
>> ferruh.yigit@intel.com; arybchenko@solarflare.com;
>> stephen@networkplumber.org
>> Subject: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct
>>
>> Struct rte_eth_rxq_info will be modified to include a new field, indicating the
>> size of each buffer that could be used for hw to receive packets. Add this
>> field to rte_eth_rxq_info to expose relevant information to upper layer
>> users/application.
>>
>> For more details:
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.
>> dpdk.org%2Farchives%2Fdev%2F2020-
>> July%2F176135.html&amp;data=02%7C01%7Cviacheslavo%40mellanox.com
>> %7Cdb0d8bcc221145a4a67508d839bd9f14%7Ca652971c7d2e4d9ba6a4d149
>> 256f461b%7C0%7C0%7C637322833881598698&amp;sdata=W2G3iEdepIjSlp
>> Wq4296k7cmXV1RhMnfl88TAjivWLc%3D&amp;reserved=0
>>
>> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> ---
>>  v2:
>>  - Remove field name.
>>  - Fix some spelling mistakes.
>> ---
>>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst
>> b/doc/guides/rel_notes/deprecation.rst
>> index ea4cfa7..f08b5f9 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -110,6 +110,15 @@ Deprecation Notices
>>    break the ABI checks, that is why change is planned for 20.11.
>>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
>>
>> +* ethdev: A new field will be added to the public data structure
>> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving
>> +packets
>> +  for HW. When receive packets, HW DMA won't exceed this size. And it
>> +will
>> +  affect the number of fragments in receiving packets when scatter is
>> enabled.
>> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant
>> +information to
>> +  upper layer user/application.
>> +  This change is planned for 20.11. For more details:
>> +
>> +https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
>> s
>> +.dpdk.org%2Farchives%2Fdev%2F2020-
>> July%2F176135.html&amp;data=02%7C01%7
>> +Cviacheslavo%40mellanox.com%7Cdb0d8bcc221145a4a67508d839bd9f14
>> %7Ca65297
>> +1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637322833881598698&amp
>> ;sdata=W2G3i
>> +EdepIjSlpWq4296k7cmXV1RhMnfl88TAjivWLc%3D&amp;reserved=0
>> +
>>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly
>> made
>>    ABI stable in the v19.11 release. The TM maintainer and other contributors
>> have
>>    agreed to keep the TM APIs as experimental in expectation of additional
>> spec
>> --
>> 2.7.4
> We are going to introduce the more flexible format to descript the rx buffers
> with multiple segment lengths/pools. It might be worth to consider extending this
> info structure single field to array. I suppose it is the subject for further discussion (on RFC).

I saw your announcement about changing rxconf structure, and it looks interesting.
I am not sure if I need to mention this in v3?

> 
> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> 
> 
> 
> .
> 

Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct

[Thomas Monjalon]

For info, today is the last day to get trusted acks on deprecations.

07/08/2020 05:51, Chengchang Tang:
> On 2020/8/6 23:25, Ferruh Yigit wrote:
> > On 8/6/2020 5:00 AM, Chengchang Tang wrote:
> >> Struct rte_eth_rxq_info will be modified to include a new field, indicating
> >> the size of each buffer that could be used for hw to receive packets. Add
> >> this field to rte_eth_rxq_info to expose relevant information to upper
> >> layer users/application.
> >>
> >> For more details:
> >> https://mails.dpdk.org/archives/dev/2020-July/176135.html
> >>
> >> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> >> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> >> ---
> >>  doc/guides/rel_notes/deprecation.rst | 9 +++++++++
> >>  1 file changed, 9 insertions(+)
> >>
> >> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> >> index ea4cfa7..f08b5f9 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -110,6 +110,15 @@ Deprecation Notices
> >>    break the ABI checks, that is why change is planned for 20.11.
> >>    The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``.
> >>  
> >> +* ethdev: A new field will be added to the public data structure
> >> +  ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets
> >> +  for HW. When receive packets, HW DMA won't exceed this size.
> > 
> > Overall +1 to provide this information.
> > 
> > This field is only to report back the PMD configured Rx buffer size, it won't
> > affect the configuration step, do you think should we highlight this?
> I think it is not necessary because this structure is designed to report PMD
> configuration. And it is only used in rte_eth_rx_queue_info_get.
> > 
> > Also will this field be optional or mandatory, this matters for the scope of the
> > work for 20.11. I think the intention is to provide an optional field, what do
> > you think to documenting that it is optional?
> Yes, it is optional. I will highlight this in v3.
> > 
> >> And it will
> >> +  affect the number of fragments in receiving packets when scatter is enabled.
> > 
> > Is this detail required in the deprecation notice? I see it is relevant but
> > the configured Rx buffer size affects the number of the fragments, but reporting
> > this value does not.
> > Do you want to mention above as motivation to have the field? If so I don't
> > expect application to calculate the number of the fragments using this value.
> > I am for dropping above sentences if I am not missing anything.
> Thank you for this advice. I am not sure what information should be reflected in
> a deprecation notice. I seem to have added some redundant and inappropriate stuff.
> I will drop these sentences in v3.
> > 
> >> +  So, add this field to ``rte_eth_rxq_info`` to expose relevant information to
> >> +  upper layer user/application.
> > 
> > And not sure above sentences says anything new, looks like duplication to me.
> > 
> >> +  This change is planned for 20.11. For more details:
> >> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html
> >> +
> >>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
> >>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
> >>    agreed to keep the TM APIs as experimental in expectation of additional spec
> >>
> > 
> > 
> > .
> > 
> 
> 

[dpdk-dev] [PATCH v3] doc: add new field to rxq info struct

[Chengchang Tang]

Struct rte_eth_rxq_info will be modified to include a new field, indicating
the size of each buffer that could be used for HW to receive packets. Add
this field to rte_eth_rxq_info to expose relevant information to upper
layer users/application.

For more details:
https://mails.dpdk.org/archives/dev/2020-July/176135.html

Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
---
 v3:
 - Remove redundant sentences.
 v2:
 - Remove field name.
 - Fix some spelling mistake.
---
 doc/guides/rel_notes/deprecation.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 9af3ce0..057178d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -195,6 +195,11 @@ Deprecation Notices
   following the IPv6 header, as proposed in RFC
   https://mails.dpdk.org/archives/dev/2020-August/177257.html.

+* ethdev: The ``struct rte_eth_rxq_info`` struct will be modified to include
+  a new optional field, indicating the buffer size used in receiving packets
+  for HW. This change is planned for 20.11. For more details:
+  https://mails.dpdk.org/archives/dev/2020-July/176135.html.
+
 * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
   ABI stable in the v19.11 release. The TM maintainer and other contributors have
   agreed to keep the TM APIs as experimental in expectation of additional spec
--
2.7.4

Re: [dpdk-dev] [PATCH v3] doc: add new field to rxq info struct

[Ferruh Yigit]

On 8/7/2020 11:30 AM, Chengchang Tang wrote:
> Struct rte_eth_rxq_info will be modified to include a new field, indicating
> the size of each buffer that could be used for HW to receive packets. Add
> this field to rte_eth_rxq_info to expose relevant information to upper
> layer users/application.
> 
> For more details:
> https://mails.dpdk.org/archives/dev/2020-July/176135.html
> 
> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> ---
>  v3:
>  - Remove redundant sentences.
>  v2:
>  - Remove field name.
>  - Fix some spelling mistake.
> ---
>  doc/guides/rel_notes/deprecation.rst | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 9af3ce0..057178d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -195,6 +195,11 @@ Deprecation Notices
>    following the IPv6 header, as proposed in RFC
>    https://mails.dpdk.org/archives/dev/2020-August/177257.html.
> 
> +* ethdev: The ``struct rte_eth_rxq_info`` struct will be modified to include
> +  a new optional field, indicating the buffer size used in receiving packets
> +  for HW. This change is planned for 20.11. For more details:
> +  https://mails.dpdk.org/archives/dev/2020-July/176135.html.
> +
>  * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made
>    ABI stable in the v19.11 release. The TM maintainer and other contributors have
>    agreed to keep the TM APIs as experimental in expectation of additional spec
> --
> 2.7.4
> 

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Re: [dpdk-dev] [PATCH v3] doc: add new field to rxq info struct

[Thomas Monjalon]

07/08/2020 12:35, Ferruh Yigit:
> On 8/7/2020 11:30 AM, Chengchang Tang wrote:
> > Struct rte_eth_rxq_info will be modified to include a new field, indicating
> > the size of each buffer that could be used for HW to receive packets. Add
> > this field to rte_eth_rxq_info to expose relevant information to upper
> > layer users/application.
> > 
> > For more details:
> > https://mails.dpdk.org/archives/dev/2020-July/176135.html
> > 
> > Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
> > Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> > ---
> > +* ethdev: The ``struct rte_eth_rxq_info`` struct will be modified to include
> > +  a new optional field, indicating the buffer size used in receiving packets
> > +  for HW. This change is planned for 20.11. For more details:
> > +  https://mails.dpdk.org/archives/dev/2020-July/176135.html.
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

I think this notice is useless as the struct has __rte_cache_min_aligned.
Others have approved, so
Applied