doc: add new field to rxq info struct

Message ID 1596619484-19714-1-git-send-email-tangchengchang@huawei.com (mailing list archive)
State Superseded, archived
Headers
Series doc: add new field to rxq info struct |

Checks

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

Commit Message

Chengchang Tang Aug. 5, 2020, 9:24 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>
---
 doc/guides/rel_notes/deprecation.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

--
2.7.4
  

Comments

Andrew Rybchenko Aug. 5, 2020, 11:25 a.m. UTC | #1
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
>
  

Patch

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