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 DEA0CA0548; Thu, 2 Jun 2022 15:20:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CDA0740E09; Thu, 2 Jun 2022 15:20:31 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0875240DF7 for ; Thu, 2 Jun 2022 15:20:31 +0200 (CEST) Received: from [192.168.1.126] (unknown [188.242.181.57]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 89841C8; Thu, 2 Jun 2022 16:20:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 89841C8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1654176030; bh=gUGh6m/nfTVLCReheWSKTpRqzTxxD9HPOGnk9zNIVMU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mIjrYRw//5AeSKnqM4VtLYAaV2Ul9SlP1eQLNQKF29np0m+naxcikExdhnshYYx8t S03DM/4ZPqEWZX/7qNub+X5w1/8AT5EVhNwkmvwK6AfLeU8StHxYkec5ULR5eK9+fQ 0pArlOHLhPuHX5gCu8Ni+rHfcgIqy8YpBCY0G9pI= Message-ID: Date: Thu, 2 Jun 2022 16:20:30 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v8 1/3] ethdev: introduce protocol header based buffer split Content-Language: en-US To: wenxuanx.wu@intel.com, thomas@monjalon.net, 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 Cc: stephen@networkplumber.org, Xuan Ding , Yuan Wang , Ray Kinsella References: <20220303060136.36427-1-xuan.ding@intel.com> <20220601135059.958882-1-wenxuanx.wu@intel.com> <20220601135059.958882-3-wenxuanx.wu@intel.com> From: Andrew Rybchenko In-Reply-To: <20220601135059.958882-3-wenxuanx.wu@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 There are two v8 1/3 patches in my mailbox. Which one is the right one? On 6/1/22 16:50, wenxuanx.wu@intel.com wrote: > 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 > Acked-by: Ray Kinsella [snip]