[v3] doc: add new field to rxq info struct
Checks
Commit Message
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(+)
--
2.7.4
Comments
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>
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
@@ -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