[v2] doc: add new field to rxq info struct

Message ID 1596686446-8138-2-git-send-email-tangchengchang@huawei.com (mailing list archive)
State Superseded, archived
Headers
Series [v2] doc: add new field to rxq info struct |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/travis-robot success Travis build: passed
ci/Intel-compilation success Compilation OK

Commit Message

Chengchang Tang Aug. 6, 2020, 4 a.m. UTC
  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(+)
  

Comments

Ferruh Yigit Aug. 6, 2020, 3:25 p.m. UTC | #1
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
>
  
Chengchang Tang Aug. 7, 2020, 3:51 a.m. UTC | #2
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
>>
> 
> 
> .
>
  
Thomas Monjalon Aug. 7, 2020, 7:41 a.m. UTC | #3
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
> >>
> > 
> > 
> > .
> > 
> 
>
  

Patch

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