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 0498DA00C5; Fri, 8 Jul 2022 17:00:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 077A6410E8; Fri, 8 Jul 2022 17:00:52 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id BFADC410E8 for ; Fri, 8 Jul 2022 17:00:50 +0200 (CEST) Received: from [192.168.1.38] (unknown [188.170.75.69]) (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 05769BC; Fri, 8 Jul 2022 18:00:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 05769BC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1657292450; bh=jd9QS2FVbzOZs4cAec5fi5iCkpP28QGliFuhSdO2PFo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TINHPigsLqv2ciO0rmAK0r6h7v+gHkQEHi5xN/R68r+PAkToyZvN45cMCzGHP3212 Jm+U5jxVDSFpHeirHCVcNS8hEM5gRH38zlijMTEpmFgpviTIvh7vWmknIwkquRiXtI Jx5OejHtoERS2wUloyN7+T13ecrIls1ecTLIm+fI= Message-ID: <7f8f4017-c924-9533-0914-3792c32b5804@oktetlabs.ru> Date: Fri, 8 Jul 2022 18:00:47 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v9 2/4] ethdev: introduce protocol hdr 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> <20220613102550.241759-1-wenxuanx.wu@intel.com> <20220613102550.241759-3-wenxuanx.wu@intel.com> From: Andrew Rybchenko In-Reply-To: <20220613102550.241759-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 On 6/13/22 13:25, 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 an arbitrarily variable length in Rx > packet segment, it is almost impossible to pass a fixed protocol header to > driver. 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, driver 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" */ There is a big problem here that using RTE_PTYPE_* defines I can't request split after either TCP or UDP header. > }; > > If both inner and outer L2/L3/L4 level protocol header split can be > supported by a PMD. 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. I think there is no point to list above defines here if it is not the only supported defines. > > 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 Sorry, but I still see no definition what should happen with, for example, ARP packet with above config. > > Now buffer 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 driver 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: Wenxuan Wu > Signed-off-by: Yuan Wang > Reviewed-by: Qi Zhang > Acked-by: Ray Kinsella > --- > lib/ethdev/rte_ethdev.c | 32 +++++++++++++++++++++++++++++++- > lib/ethdev/rte_ethdev.h | 14 +++++++++++++- > 2 files changed, 44 insertions(+), 2 deletions(-) Do we need a dedicated feature in doc/guides/nics/features.rst? Or should be just update buffer split to refer to a new supported header split API and callback? Also the feature definitely deserves entry in the release notes. [snip]