[v9,0/4] add an api to support proto based buffer split

  From: Wenxuan Wu <wenxuanx.wu@intel.com>

Protocol type based buffer split consists of splitting a received packet into
several separate segments based on the packet content. It is useful in some
scenarios, such as GPU acceleration. The splitting will help to enable
true zero copy and hence improve the performance significantly.

This patchset aims to support protocol header split based on current buffer
split. When Rx queue is configured with RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT
offload and corresponding protocol, packets received will be directly split
into different mempools.

v8->v9:
* Introduce a new api rte_eth_supported_hdrs_get to retrieve supported
  ptypes mask of a pmd to split.
* Fix header protocol split check.
* Support header protocol configuration of rxhdrs by default, e.g.
  ipv4, ipv6, mac, inner_mac, outer_mac, l3, l4.
* Refine doc.

v7->v8:
* Refine ethdev doc.
* Fix header protocol split check.

v6->v7:
* Fix supported header protocol check.
* Add rxhdrs commands and parameters.

v5->v6:
* The header split deprecation notice is sent.
* Refine the documents, protocol header based buffer split can actually
  support multi-segment split.
* Add buffer split protocol header capability.
* Fix some format issues.

v4->v5:
* Use protocol and mbuf_offset based buffer split instead of header split.
* Use RTE_PTYPE* instead of enum rte_eth_rx_header_split_protocol_type.
* Improve the description of rte_eth_rxseg_split.proto.

v3->v4:
* Use RTE_ETH_RX_HEADER_SPLIT_NONE instead of 0.

v2->v3:
* Fix a PMD bug.
* Add rx queue header split check.
* Revise the log and doc.

v1->v2:
* Add support for all header split protocol types.

Wenxuan Wu (4):
  ethdev: introduce protocol header API
  ethdev: introduce protocol hdr based buffer split
  app/testpmd: add rxhdrs commands and parameters
  net/ice: support buffer split in Rx path

 app/test-pmd/cmdline.c                 | 133 ++++++++++++++-
 app/test-pmd/config.c                  |  75 +++++++++
 app/test-pmd/parameters.c              |  15 +-
 app/test-pmd/testpmd.c                 |   6 +-
 app/test-pmd/testpmd.h                 |   6 +
 doc/guides/rel_notes/release_22_07.rst |   2 +
 drivers/net/ice/ice_ethdev.c           |  38 ++++-
 drivers/net/ice/ice_rxtx.c             | 220 +++++++++++++++++++++----
 drivers/net/ice/ice_rxtx.h             |  16 ++
 drivers/net/ice/ice_rxtx_vec_common.h  |   3 +
 lib/ethdev/ethdev_driver.h             |  18 ++
 lib/ethdev/rte_ethdev.c                |  61 +++++--
 lib/ethdev/rte_ethdev.h                |  36 +++-
 lib/ethdev/version.map                 |   3 +
 14 files changed, 582 insertions(+), 50 deletions(-)
  

Hi Andrew,

> -----Original Message-----
> From: wenxuanx.wu@intel.com <wenxuanx.wu@intel.com>
> Sent: Monday, June 13, 2022 6:26 PM
> To: thomas@monjalon.net; andrew.rybchenko@oktetlabs.ru; Li, Xiaoyun
> <xiaoyun.li@intel.com>; ferruh.yigit@xilinx.com; Singh, Aman Deep
> <aman.deep.singh@intel.com>; dev@dpdk.org; Zhang, Yuying
> <yuying.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> jerinjacobk@gmail.com
> Cc: stephen@networkplumber.org; Wu, WenxuanX
> <wenxuanx.wu@intel.com>
> Subject: [PATCH v9 0/4] add an api to support proto based buffer split
> 
> From: Wenxuan Wu <wenxuanx.wu@intel.com>
> 
> Protocol type based buffer split consists of splitting a received packet into
> several separate segments based on the packet content. It is useful in some
> scenarios, such as GPU acceleration. The splitting will help to enable true
> zero copy and hence improve the performance significantly.
> 
> This patchset aims to support protocol header split based on current buffer
> split. When Rx queue is configured with
> RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT offload and corresponding protocol,
> packets received will be directly split into different mempools.

This protocol based buffer split patch series have been updated to v9.
Sincerely thank you for the effort you put into this series.

Hope to know your considerations about this series now.
Do you think is it possible to get in 22.07? Or there are still some critical gaps need to be solved?
Because we don't hope the same thing happens in 22.11.

Thanks very much.

Regards,
Xuan

> 
> v8->v9:
> * Introduce a new api rte_eth_supported_hdrs_get to retrieve supported
>   ptypes mask of a pmd to split.
> * Fix header protocol split check.
> * Support header protocol configuration of rxhdrs by default, e.g.
>   ipv4, ipv6, mac, inner_mac, outer_mac, l3, l4.
> * Refine doc.
> 
> v7->v8:
> * Refine ethdev doc.
> * Fix header protocol split check.
> 
> v6->v7:
> * Fix supported header protocol check.
> * Add rxhdrs commands and parameters.
> 
> v5->v6:
> * The header split deprecation notice is sent.
> * Refine the documents, protocol header based buffer split can actually
>   support multi-segment split.
> * Add buffer split protocol header capability.
> * Fix some format issues.
> 
> v4->v5:
> * Use protocol and mbuf_offset based buffer split instead of header split.
> * Use RTE_PTYPE* instead of enum rte_eth_rx_header_split_protocol_type.
> * Improve the description of rte_eth_rxseg_split.proto.
> 
> v3->v4:
> * Use RTE_ETH_RX_HEADER_SPLIT_NONE instead of 0.
> 
> v2->v3:
> * Fix a PMD bug.
> * Add rx queue header split check.
> * Revise the log and doc.
> 
> v1->v2:
> * Add support for all header split protocol types.
> 
> Wenxuan Wu (4):
>   ethdev: introduce protocol header API
>   ethdev: introduce protocol hdr based buffer split
>   app/testpmd: add rxhdrs commands and parameters
>   net/ice: support buffer split in Rx path
> 
>  app/test-pmd/cmdline.c                 | 133 ++++++++++++++-
>  app/test-pmd/config.c                  |  75 +++++++++
>  app/test-pmd/parameters.c              |  15 +-
>  app/test-pmd/testpmd.c                 |   6 +-
>  app/test-pmd/testpmd.h                 |   6 +
>  doc/guides/rel_notes/release_22_07.rst |   2 +
>  drivers/net/ice/ice_ethdev.c           |  38 ++++-
>  drivers/net/ice/ice_rxtx.c             | 220 +++++++++++++++++++++----
>  drivers/net/ice/ice_rxtx.h             |  16 ++
>  drivers/net/ice/ice_rxtx_vec_common.h  |   3 +
>  lib/ethdev/ethdev_driver.h             |  18 ++
>  lib/ethdev/rte_ethdev.c                |  61 +++++--
>  lib/ethdev/rte_ethdev.h                |  36 +++-
>  lib/ethdev/version.map                 |   3 +
>  14 files changed, 582 insertions(+), 50 deletions(-)
> 
> --
> 2.25.1
  

21/06/2022 10:56, Ding, Xuan:
> This protocol based buffer split patch series have been updated to v9.
> Sincerely thank you for the effort you put into this series.
> 
> Hope to know your considerations about this series now.
> Do you think is it possible to get in 22.07? Or there are still some critical gaps need to be solved?
> Because we don't hope the same thing happens in 22.11.

My quick comment, I think you must better care about all details.
Precise explanations are very important.
It is more encouraging to review when we see the author tried hard
to avoid any confusion or approximation.
  

Hi,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, July 7, 2022 5:10 PM
> To: Wu, WenxuanX <wenxuanx.wu@intel.com>; Ding, Xuan
> <xuan.ding@intel.com>
> Cc: andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; Li, Xiaoyun
> <xiaoyun.li@intel.com>; ferruh.yigit@xilinx.com; dev@dpdk.org; Zhang,
> Yuying <yuying.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> jerinjacobk@gmail.com; stephen@networkplumber.org; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>;
> Mcnamara, John <john.mcnamara@intel.com>
> Subject: Re: [PATCH v9 0/4] add an api to support proto based buffer split
> 
> 21/06/2022 10:56, Ding, Xuan:
> > This protocol based buffer split patch series have been updated to v9.
> > Sincerely thank you for the effort you put into this series.
> >
> > Hope to know your considerations about this series now.
> > Do you think is it possible to get in 22.07? Or there are still some critical
> gaps need to be solved?
> > Because we don't hope the same thing happens in 22.11.
> 
> My quick comment, I think you must better care about all details.
> Precise explanations are very important.
> It is more encouraging to review when we see the author tried hard to avoid
> any confusion or approximation.

Thanks a lot to all the reviewers for the effort on this series.
So far, although we tried to make the explanation or documentation detailed,
there must have some places that are not clearly explained or the doc is not good enough.

We will do more self-checks and try to refine where it might not be clear.
Your comments are welcome.

Regards,
Xuan

> 
>