From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BCED6A04A2; Thu, 3 Mar 2022 09:55:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5010640687; Thu, 3 Mar 2022 09:55:13 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 54ABE40141 for ; Thu, 3 Mar 2022 09:55:11 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id B5B5358024D; Thu, 3 Mar 2022 03:55:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 03 Mar 2022 03:55:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=s+N8Etq4gUi7OP BX11DpuJDyz9SBAv2xEsT2gSbUaQk=; b=sUzvD8jZfJRLl0AjQ9c7g07UgmzZZX Pq3SwnyB9swYSqyz2GxjQGK0nz753ynY4H83reP5rGkz0yMod2CT1I68rn2yysge JPn/qbXwINitXJp0yk+UmX+IotWw/AT8rr6HvLo+AzDj+YprEEVj5Qhc0Ow7rAqj /JoYneSeieZ1E6n2dD0PhRutlInNVdruytFOcPD+oHN/EiQ7Br682uy8f9pRtief odXKS+bhMuJc/nF2/UPHje/jx4qpdx7jD8IpqZ0TgOwNB+z4oa5/NokvkQtAulA6 rDvlsHm7NDjoFDOzZf331XchcH0ftm/JLspySFNNK/JrXuHTDKiLKYWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=s+N8Etq4gUi7OPBX11DpuJDyz9SBAv2xEsT2gSbUa Qk=; b=EucyLTWbqFeGyIDq09rL3J8LwIVTlX1uYNnJKZKEStmAraYAGLgtJwOZP XMddmB9xANAJ6OtLevAFhrfkEOCJUQb80eay5zte9m0bLxmfvTx/gfPRPx1nYGOv eFql4ZebYEVVWSE+waim+bBTkzOn8wXQnIPuAJVFD/Rj1DKyLhkVpBKHBlLxeamY YcGtd/5qW3IZdZRnryxPfjVSMhTykxEkbOQYefRX6LQJmpCbqcRXoxWxaKVAgcHf e+SOBWgJs3Z3kLWicWXvxoIEct2BGMVaNQngPNls6tLlGN+K6TUky6ZF/fhGxPTN zzl6pZ6M3GvByQBMpEcu3u1sD3pBg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddthedguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 3 Mar 2022 03:55:08 -0500 (EST) From: Thomas Monjalon To: xuan.ding@intel.com Cc: ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, viacheslavo@nvidia.com, qi.z.zhang@intel.com, ping.yu@intel.com, Xuan Ding , Yuan Wang , ajit.khaparde@broadcom.com, jerinj@marvell.com Subject: Re: [RFC] ethdev: introduce protocol type based header split Date: Thu, 03 Mar 2022 09:55:07 +0100 Message-ID: <5016713.VdNmn5OnKV@thomas> In-Reply-To: <20220303060136.36427-1-xuan.ding@intel.com> References: <20220303060136.36427-1-xuan.ding@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 03/03/2022 07:01, xuan.ding@intel.com: > From: Xuan Ding > > Header split consists of splitting a received packet into two separate > regions based on the packet content. Splitting is usually between the > packet header that can be posted to a dedicated buffer and the packet > payload that can be posted to a different buffer. This kind of splitting > is useful in some use cases, such as GPU. GPU can directly process the > payload part and improve the performance significantly. > > Currently, Rx buffer split supports length and offset based packet split. > This is not suitable for some NICs that do split based on protocol types. > Tunneling makes the conversion from offset to protocol inaccurate. > > This patch extends the current buffer split to support protocol based > header split. A new proto field is introduced in the rte_eth_rxseg_split > structure reserved field to specify header split type. > > With Rx offload flag RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and protocol > type configured, PMD will split the ingress packets into two separate > regions. Currently, L2/L3/L4 level header split is supported. > > Signed-off-by: Xuan Ding > Signed-off-by: Yuan Wang > --- > lib/ethdev/rte_ethdev.c | 2 +- > lib/ethdev/rte_ethdev.h | 17 ++++++++++++++++- > 2 files changed, 17 insertions(+), 2 deletions(-) > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c > index 70c850a2f1..d37c8f9d7e 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -1784,7 +1784,7 @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id, > &dev_info); > if (ret != 0) > return ret; > - } else { > + } else if (!(rx_conf->offloads & RTE_ETH_RX_OFFLOAD_HEADER_SPLIT)) { > RTE_ETHDEV_LOG(ERR, "No Rx segmentation offload configured\n"); > return -EINVAL; > } > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index c2d1f9a972..6743648c22 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1202,7 +1202,8 @@ 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. */ > + uint16_t proto; If it is not explicitly documented, it cannot be accepted. What happens if we have a non-0 proto and length/offset defined? > + uint16_t reserved; /**< Reserved field. */ > }; [...] > +/** > + * @warning > + * @b EXPERIMENTAL: this structure may change without prior notice. This is not a structure. > + * This enum indicates the header split protocol type > + */ > +enum rte_eth_rx_header_split_protocol_type { > + RTE_ETH_RX_HEADER_SPLIT_DEFAULT = 0, > + RTE_ETH_RX_HEADER_SPLIT_INNER_L2, > + RTE_ETH_RX_HEADER_SPLIT_OUTER_L2, > + RTE_ETH_RX_HEADER_SPLIT_IP, > + RTE_ETH_RX_HEADER_SPLIT_TCP_UDP, > + RTE_ETH_RX_HEADER_SPLIT_SCTP > +}; Lack of documentation. Where the split should happen? before or after the header? What means DEFAULT? What means IP, TCP_UDP and SCTP? Is it inner or outer?