All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: xuan.ding@intel.com, yuanx.wang@intel.com, wenxuanx.wu@intel.com
Cc: andrew.rybchenko@oktetlabs.ru, xiaoyun.li@intel.com,
	ferruh.yigit@xilinx.com, aman.deep.singh@intel.com, dev@dpdk.org,
	yuying.zhang@intel.com, qi.z.zhang@intel.com,
	jerinjacobk@gmail.com, stephen@networkplumber.org,
	mb@smartsharesystems.com, viacheslavo@nvidia.com,
	ping.yu@intel.com
Subject: Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split
Date: Tue, 17 May 2022 23:12:00 +0200	[thread overview]
Message-ID: <13015742.y0N7aAr316@thomas> (raw)
In-Reply-To: <20220426111338.1074785-2-wenxuanx.wu@intel.com>

Hello,

It seems you didn't try to address my main comment on v4:
"
Before doing anything, the first patch of this series should make
the current status clearer.
Example, this line does not explain what it does:
        uint16_t split_hdr_size;  /**< hdr buf size (header_split enabled).*/
And header_split has been removed in ab3ce1e0c193 ("ethdev: remove old offload API")

If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed,
let's add a comment to start a deprecation.
"

Also the comment from Andrew about removing limitation to 2 packets
is not addressed.

All the part about the protocols capability is missing here.

It is not encouraging.

26/04/2022 13:13, wenxuanx.wu@intel.com:
> From: Wenxuan Wu <wenxuanx.wu@intel.com>
> 
> Protocol based buffer split consists of splitting a received packet into two
> separate regions based on its content. The split happens after the packet
> protocol header and before the packet payload. Splitting is usually between
> the packet protocol header that can be posted to a dedicated buffer and the
> packet payload that can be posted to a different buffer.
> 
> Currently, Rx buffer split supports length and offset based packet split.
> protocol split is based on buffer split, configuring length of buffer split
> is not suitable for NICs that do split based on protocol types.

Why? Is it impossible to support length split on Intel NIC?

> Because tunneling makes the conversion from length
> to protocol type impossible.

This is not a HW issue.
I agree on the need but that a different usage than length split.

> This patch extends the current buffer split to support protocol and offset
> based buffer split. A new proto field is introduced in the rte_eth_rxseg_split
> structure reserved field to specify header protocol type. With Rx queue
> offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and corresponding protocol
> type configured. PMD will split the ingress packets into two separate regions.
> Currently, both inner and outer L2/L3/L4 level protocol based buffer split
> can be supported.
> 
> For example, let's suppose we configured the Rx queue with the
> following segments:
>     seg0 - pool0, off0=2B
>     seg1 - pool1, off1=128B
> 
> With protocol split type configured with RTE_PTYPE_L4_UDP. The packet
> consists of MAC_IP_UDP_PAYLOAD will be splitted like following:
>     seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
>     seg1 - payload @ 128 in mbuf from pool1

Not clear what is the calculation.

> The memory attributes for the split parts may differ either - for example
> the mempool0 and mempool1 belong to dpdk memory and external memory,
> respectively.
> 
> Signed-off-by: Xuan Ding <xuan.ding@intel.com>
> Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> Signed-off-by: Wenxuan Wu <wenxuanx.wu@intel.com>
> Reviewed-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
>  lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++-------
>  lib/ethdev/rte_ethdev.h | 15 ++++++++++++++-
>  2 files changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 29a3d80466..1a2bc172ab 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,
>  		struct rte_mempool *mpl = rx_seg[seg_idx].mp;
>  		uint32_t length = rx_seg[seg_idx].length;
>  		uint32_t offset = rx_seg[seg_idx].offset;
> +		uint32_t proto = rx_seg[seg_idx].proto;
>  
>  		if (mpl == NULL) {
>  			RTE_ETHDEV_LOG(ERR, "null mempool pointer\n");
> @@ -1694,13 +1695,34 @@ rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg,
>  		}
>  		offset += seg_idx != 0 ? 0 : RTE_PKTMBUF_HEADROOM;
>  		*mbp_buf_size = rte_pktmbuf_data_room_size(mpl);
> -		length = length != 0 ? length : *mbp_buf_size;
> -		if (*mbp_buf_size < length + offset) {
> -			RTE_ETHDEV_LOG(ERR,
> -				       "%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n",
> -				       mpl->name, *mbp_buf_size,
> -				       length + offset, length, offset);
> -			return -EINVAL;
> +		if (proto == 0) {

Add a comment here, /* split at fixed length */

> +			length = length != 0 ? length : *mbp_buf_size;
> +			if (*mbp_buf_size < length + offset) {
> +				RTE_ETHDEV_LOG(ERR,
> +					"%s mbuf_data_room_size %u < %u (segment length=%u + segment offset=%u)\n",
> +					mpl->name, *mbp_buf_size,
> +					length + offset, length, offset);
> +				return -EINVAL;
> +			}
> +		} else {

Add a comment here, /* split after specified protocol header */

> +			/* Ensure n_seg is 2 in protocol based buffer split. */
> +			if (n_seg != 2)	{

(should be a space, not a tab before brace)

Why do you limit the feature to 2 segments only?

> +				RTE_ETHDEV_LOG(ERR, "number of buffer split protocol segments should be 2.\n");
> +				return -EINVAL;
> +			}
> +			/* Length and protocol are exclusive here, so make sure length is 0 in protocol
> +			based buffer split. */
> +			if (length != 0) {
> +				RTE_ETHDEV_LOG(ERR, "segment length should be set to zero in buffer split\n");
> +				return -EINVAL;
> +			}
> +			if (*mbp_buf_size < offset) {
> +				RTE_ETHDEV_LOG(ERR,
> +						"%s mbuf_data_room_size %u < %u segment offset)\n",
> +						mpl->name, *mbp_buf_size,
> +						offset);
> +				return -EINVAL;
[...]
> + * - The proto in the elements defines the split position of received packets.
> + *
>   * - If the length in the segment description element is zero
>   *   the actual buffer size will be deduced from the appropriate
>   *   memory pool properties.
> @@ -1197,12 +1200,21 @@ struct rte_eth_txmode {
>   *     - pool from the last valid element
>   *     - the buffer size from this pool
>   *     - zero offset
> + *
> + * - Length based buffer split:
> + *     - mp, length, offset should be configured.
> + *     - The proto should not be configured in length split. Zero default.
> + *
> + * - Protocol based buffer split:
> + *     - mp, offset, proto should be configured.
> + *     - The length should not be configured in protocol split. Zero default.

What means "Zero default"?
You should just ignore the non relevant field.

>  struct rte_eth_rxseg_split {
>  	struct rte_mempool *mp; /**< Memory pool to allocate segment from. */
>  	uint16_t length; /**< Segment data length, configures split point. */
>  	uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> -	uint32_t reserved; /**< Reserved field. */

How do you manage ABI compatibility?
Was the reserved field initialized to 0 in previous versions?

> +	uint32_t proto; /**< Protocol of buffer split, determines protocol split point. */

What are the values for "proto"?

> @@ -1664,6 +1676,7 @@ struct rte_eth_conf {
>  			     RTE_ETH_RX_OFFLOAD_QINQ_STRIP)
>  #define DEV_RX_OFFLOAD_VLAN RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN) RTE_ETH_RX_OFFLOAD_VLAN
>  
> +

It looks to be an useless change.

>  /*
>   * If new Rx offload capabilities are defined, they also must be
>   * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> 






  reply	other threads:[~2022-05-17 21:12 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03  6:01 [RFC] ethdev: introduce protocol type based header split xuan.ding
2022-03-03  8:55 ` Thomas Monjalon
2022-03-08  7:48   ` Ding, Xuan
2022-03-03 16:15 ` Stephen Hemminger
2022-03-04  9:58   ` Zhang, Qi Z
2022-03-04 11:54     ` Morten Brørup
2022-03-04 17:32     ` Stephen Hemminger
2022-03-22  3:56 ` [RFC,v2 0/3] " xuan.ding
2022-03-22  3:56   ` [RFC,v2 1/3] " xuan.ding
2022-03-22  7:14     ` Zhang, Qi Z
2022-03-22  7:43       ` Ding, Xuan
2022-03-22  3:56   ` [RFC,v2 2/3] app/testpmd: add header split configuration xuan.ding
2022-03-22  3:56   ` [RFC,v2 3/3] net/ice: support header split in Rx data path xuan.ding
2022-03-29  6:49 ` [RFC,v3 0/3] ethdev: introduce protocol type based header split xuan.ding
2022-03-29  6:49   ` [RFC,v3 1/3] " xuan.ding
2022-03-29  7:56     ` Zhang, Qi Z
2022-03-29  8:18       ` Ding, Xuan
2022-03-29  6:49   ` [RFC,v3 2/3] app/testpmd: add header split configuration xuan.ding
2022-03-29  6:49   ` [RFC,v3 3/3] net/ice: support header split in Rx data path xuan.ding
2022-04-02 10:41 ` [v4 0/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-04-02 10:41   ` [v4 1/3] " wenxuanx.wu
2022-04-07 10:47     ` Andrew Rybchenko
2022-04-12 16:15       ` Ding, Xuan
2022-04-20 15:48         ` Andrew Rybchenko
2022-04-25 14:57           ` Ding, Xuan
2022-04-21 10:27         ` Thomas Monjalon
2022-04-25 15:05           ` Ding, Xuan
2022-04-07 13:26     ` Jerin Jacob
2022-04-12 16:40       ` Ding, Xuan
2022-04-20 14:39         ` Andrew Rybchenko
2022-04-21 10:36           ` Thomas Monjalon
2022-04-25  9:23           ` Ding, Xuan
2022-04-26 11:13     ` [PATCH v5 0/3] ethdev: introduce protocol based buffer split wenxuanx.wu
2022-04-26 11:13       ` [PATCH v5 1/4] lib/ethdev: introduce protocol type " wenxuanx.wu
2022-05-17 21:12         ` Thomas Monjalon [this message]
2022-05-19 14:40           ` Ding, Xuan
2022-05-26 14:58             ` Ding, Xuan
2022-04-26 11:13       ` [PATCH v5 2/4] app/testpmd: add proto based buffer split config wenxuanx.wu
2022-04-26 11:13       ` [PATCH v5 3/4] net/ice: support proto based buf split in Rx path wenxuanx.wu
2022-04-02 10:41   ` [v4 2/3] app/testpmd: add header split configuration wenxuanx.wu
2022-04-02 10:41   ` [v4 3/3] net/ice: support header split in Rx data path wenxuanx.wu
2022-05-27  7:54 ` [PATCH v6] ethdev: introduce protocol header based buffer split xuan.ding
2022-05-27  8:14 ` [PATCH v6 0/1] ethdev: introduce protocol " xuan.ding
2022-05-27  8:14   ` [PATCH v6 1/1] ethdev: introduce protocol header " xuan.ding
2022-05-30  9:43     ` Ray Kinsella
2022-06-01 13:06 ` [PATCH v7 0/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-06-01 13:06   ` [PATCH v7 1/3] ethdev: introduce protocol header based buffer split wenxuanx.wu
2022-06-01 13:06   ` [PATCH v7 2/3] net/ice: support buffer split in Rx path wenxuanx.wu
2022-06-01 13:06   ` [PATCH v7 3/3] app/testpmd: add rxhdrs commands and parameters wenxuanx.wu
2022-06-01 13:22 ` [PATCH v7 0/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-06-01 13:22   ` [PATCH v7 1/3] ethdev: introduce protocol header based buffer split wenxuanx.wu
2022-06-01 13:22   ` [PATCH v7 2/3] net/ice: support buffer split in Rx path wenxuanx.wu
2022-06-01 13:22   ` [PATCH v7 3/3] app/testpmd: add rxhdrs commands and parameters wenxuanx.wu
2022-06-01 13:50 ` [PATCH v8 0/3] ethdev: introduce protocol type based header split wenxuanx.wu
2022-06-01 13:50   ` [PATCH v8 1/3] ethdev: introduce protocol hdr based buffer split wenxuanx.wu
2022-06-02 13:20     ` Andrew Rybchenko
2022-06-03 16:30       ` Ding, Xuan
2022-06-04 14:25         ` Andrew Rybchenko
2022-06-07 10:13           ` Ding, Xuan
2022-06-07 10:48             ` Andrew Rybchenko
2022-06-10 15:04               ` Ding, Xuan
2022-06-01 13:50   ` [PATCH v8 1/3] ethdev: introduce protocol header " wenxuanx.wu
2022-06-02 13:20     ` Andrew Rybchenko
2022-06-02 13:44       ` Ding, Xuan
2022-06-01 13:50   ` [PATCH v8 2/3] net/ice: support buffer split in Rx path wenxuanx.wu
2022-06-01 13:50   ` [PATCH v8 3/3] app/testpmd: add rxhdrs commands and parameters wenxuanx.wu
2022-06-02 13:20   ` [PATCH v8 0/3] ethdev: introduce protocol type based header split Andrew Rybchenko
2022-06-13 10:25 ` [PATCH v9 0/4] add an api to support proto based buffer split wenxuanx.wu
2022-06-13 10:25   ` [PATCH v9 1/4] ethdev: introduce protocol header API wenxuanx.wu
2022-07-07  9:05     ` Thomas Monjalon
2022-08-01  7:09       ` Wang, YuanX
2022-08-01 10:01         ` Thomas Monjalon
2022-08-02 10:12           ` Wang, YuanX
2022-07-08 15:00     ` Andrew Rybchenko
2022-08-01  7:17       ` Wang, YuanX
2022-06-13 10:25   ` [PATCH v9 2/4] ethdev: introduce protocol hdr based buffer split wenxuanx.wu
2022-07-07  9:07     ` Thomas Monjalon
2022-07-11  9:54       ` Ding, Xuan
2022-07-11 10:12         ` Thomas Monjalon
2022-07-08 15:00     ` Andrew Rybchenko
2022-07-21  3:24       ` Ding, Xuan
2022-08-01 14:28         ` Andrew Rybchenko
2022-08-02  7:22           ` Ding, Xuan
2022-06-13 10:25   ` [PATCH v9 3/4] app/testpmd: add rxhdrs commands and parameters wenxuanx.wu
2022-06-13 10:25   ` [PATCH v9 4/4] net/ice: support buffer split in Rx path wenxuanx.wu
2022-06-21  8:56   ` [PATCH v9 0/4] add an api to support proto based buffer split Ding, Xuan
2022-07-07  9:10     ` Thomas Monjalon
2022-07-11 10:08       ` Ding, Xuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13015742.y0N7aAr316@thomas \
    --to=thomas@monjalon.net \
    --cc=aman.deep.singh@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@xilinx.com \
    --cc=jerinjacobk@gmail.com \
    --cc=mb@smartsharesystems.com \
    --cc=ping.yu@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=viacheslavo@nvidia.com \
    --cc=wenxuanx.wu@intel.com \
    --cc=xiaoyun.li@intel.com \
    --cc=xuan.ding@intel.com \
    --cc=yuanx.wang@intel.com \
    --cc=yuying.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.