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

[Andrew Rybchenko <arybchenko@solarflare.com>]

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
>