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 2D3C5A04FD; Mon, 30 May 2022 11:44:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0F3C642B78; Mon, 30 May 2022 11:44:29 +0200 (CEST) Received: from mail-108-mta139.mxroute.com (mail-108-mta139.mxroute.com [136.175.108.139]) by mails.dpdk.org (Postfix) with ESMTP id 32B2842B75 for ; Mon, 30 May 2022 11:44:27 +0200 (CEST) Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta139.mxroute.com (ZoneMTA) with ESMTPSA id 181145a2db8000c327.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 30 May 2022 09:44:23 +0000 X-Zone-Loop: 737499520ab16da8f1bb265818b93e7e506c52552b70 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Type:MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To: From:References:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0qsqwwaOpEbqW01Xbn3/UJFSA1YAxc2AjSciuMNHRaY=; b=VmpkRJPCxZ9FT2MKZ0AUAbpPC7 0OdkKjAWJEDyzi+7h+MSI/FJ0q0iE4BhpnB8hWmqYtBjIzzqC6MQzI8r7m7H4SIne+cRlUyLPQbyy dBLypU9FG28MBOS7l6B/9a0eXwIKxd9+XHGbqInzk+nyRafZ1/hAO8a2SmoRNN55HwZCCg3B240kn w1sfyyVILJBUD8g4T8w0sQo0pZTaulX0wfU5VxNBjLHBRJUfTgk1R0jEtof5bkkY8Kd8LNhcNYX3P 1C3VhTYTCp5513y3asNLobTvlT/ugLAfMiMXyadH7QWPltRAKwKBYFkj2cPJvVYljN0E0VZQWGcPf v0QgCI7A==; References: <20220303060136.36427-1-xuan.ding@intel.com> <20220527081431.27793-1-xuan.ding@intel.com> <20220527081431.27793-2-xuan.ding@intel.com> User-agent: mu4e 1.6.10; emacs 27.1 From: Ray Kinsella To: xuan.ding@intel.com Cc: thomas@monjalon.net, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org, mb@smartsharesystems.com, dev@dpdk.org, qi.z.zhang@intel.com, Wenxuan Wu , Yuan Wang Subject: Re: [PATCH v6 1/1] ethdev: introduce protocol header based buffer split Date: Mon, 30 May 2022 10:43:43 +0100 In-reply-to: <20220527081431.27793-2-xuan.ding@intel.com> Message-ID: <878rqjwe18.fsf@mdr78.vserver.site> MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: mdr@ashroe.eu 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 xuan.ding@intel.com writes: > From: Wenxuan Wu > > Currently, Rx buffer split supports length based split. With Rx queue > offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and Rx packet segment > configured, PMD will be able to split the received packets into > multiple segments. > > However, length based buffer split is not suitable for NICs that do split > based on protocol headers. Given a arbitrarily variable length in Rx packet > segment, it is almost impossible to pass a fixed protocol header to PMD. > Besides, the existence of tunneling results in the composition of a packet > is various, which makes the situation even worse. > > This patch extends current buffer split to support protocol header based > buffer split. A new proto_hdr field is introduced in the reserved field > of rte_eth_rxseg_split structure to specify protocol header. The proto_hdr > field defines the split position of packet, splitting will always happens > after the protocol header defined in the Rx packet segment. When Rx queue > offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is enabled and corresponding > protocol header is configured, PMD will split the ingress packets into > multiple segments. > > struct rte_eth_rxseg_split { > > struct rte_mempool *mp; /* memory pools to allocate segment from */ > uint16_t length; /* segment maximal data length, > configures "split point" */ > uint16_t offset; /* data offset from beginning > of mbuf data buffer */ > uint32_t proto_hdr; /* inner/outer L2/L3/L4 protocol header, > configures "split point" */ > }; > > Both inner and outer L2/L3/L4 level protocol header split can be supported. > Corresponding protocol header capability is RTE_PTYPE_L2_ETHER, > RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV6, RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, > RTE_PTYPE_L4_SCTP, RTE_PTYPE_INNER_L2_ETHER, RTE_PTYPE_INNER_L3_IPV4, > RTE_PTYPE_INNER_L3_IPV6, RTE_PTYPE_INNER_L4_TCP, RTE_PTYPE_INNER_L4_UDP, > RTE_PTYPE_INNER_L4_SCTP. > > For example, let's suppose we configured the Rx queue with the > following segments: > seg0 - pool0, proto_hdr0=RTE_PTYPE_L3_IPV4, off0=2B > seg1 - pool1, proto_hdr1=RTE_PTYPE_L4_UDP, off1=128B > seg2 - pool2, off1=0B > > The packet consists of MAC_IPV4_UDP_PAYLOAD will be split like > following: > seg0 - ipv4 header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 > seg1 - udp header @ 128 in mbuf from pool1 > seg2 - payload @ 0 in mbuf from pool2 > > Now buffet split can be configured in two modes. For length based > buffer split, the mp, length, offset field in Rx packet segment should > be configured, while the proto_hdr field should not be configured. > For protocol header based buffer split, the mp, offset, proto_hdr field > in Rx packet segment should be configured, while the length field should > not be configured. > > The split limitations imposed by underlying PMD is reported in the > rte_eth_dev_info->rx_seg_capa field. The memory attributes for the split > parts may differ either, dpdk memory and external memory, respectively. > > Signed-off-by: Xuan Ding > Signed-off-by: Yuan Wang > Signed-off-by: Wenxuan Wu > Reviewed-by: Qi Zhang > --- > lib/ethdev/rte_ethdev.c | 40 +++++++++++++++++++++++++++++++++------- > lib/ethdev/rte_ethdev.h | 28 +++++++++++++++++++++++++++- > 2 files changed, 60 insertions(+), 8 deletions(-) > Acked-by: Ray Kinsella