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 8A649A0093; Wed, 20 Apr 2022 16:40:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5F73140C35; Wed, 20 Apr 2022 16:40:01 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 5D6AD406A2 for ; Wed, 20 Apr 2022 16:39:59 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id C0B2F89; Wed, 20 Apr 2022 17:39:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru C0B2F89 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1650465598; bh=pMf7IUKK90cxFdashAmD/jRCSIfqMRUz4lZKx8R2MXw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vBkDVYLfMrd8K/9h5roIWMhQYVBzYF1cZz40cD84FugtZ5HpKLdgTPVkYhzg6AJPd jIxzwJQ7oWOiBXSP/FEidtpGrmtxemrePYrnjd3iCLYmEMDTJs6xDgrlHa5bhiMI2C TlU/UyAk+nea2td3nAq0q8ahHvRYyWL1GY6S2TdM= Message-ID: Date: Wed, 20 Apr 2022 17:39:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split Content-Language: en-US To: "Ding, Xuan" , Jerin Jacob , "Wu, WenxuanX" Cc: Thomas Monjalon , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Zhang, Qi Z" , dpdk-dev , Stephen Hemminger , =?UTF-8?Q?Morten_Br=c3=b8rup?= , Viacheslav Ovsiienko , "Yu, Ping" , "Wang, YuanX" References: <20220303060136.36427-1-xuan.ding@intel.com> <20220402104109.472078-1-wenxuanx.wu@intel.com> <20220402104109.472078-2-wenxuanx.wu@intel.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 4/12/22 19:40, Ding, Xuan wrote: > Hi Jacob, > >> -----Original Message----- >> From: Jerin Jacob >> Sent: Thursday, April 7, 2022 9:27 PM >> To: Wu, WenxuanX >> Cc: Thomas Monjalon ; Andrew Rybchenko >> ; Li, Xiaoyun ; >> Singh, Aman Deep ; Zhang, Yuying >> ; Zhang, Qi Z ; dpdk-dev >> ; Stephen Hemminger ; >> Morten Brørup ; Viacheslav Ovsiienko >> ; Yu, Ping ; Ding, Xuan >> ; Wang, YuanX >> Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split >> >> On Sat, Apr 2, 2022 at 4:33 PM wrote: >>> >>> From: Xuan Ding >>> >>> Header split consists of splitting a received packet into two separate >>> regions based on the packet content. The split happens after the >>> packet header and before the packet payload. 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. >>> >>> Currently, Rx buffer split supports length and offset based packet split. >>> Although header split is a subset of buffer split, configuring buffer >>> split based on length is not suitable for NICs that do split based on >>> header protocol types. Because tunneling makes the conversion from >>> length to protocol type impossible. >>> >>> This patch extends the current buffer split to support protocol type >>> and offset based header split. A new proto field is introduced in the >>> rte_eth_rxseg_split structure reserved field to specify header >>> protocol 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, both inner and outer >>> L2/L3/L4 level header 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 header split type configured with RTE_ETH_RX_HEADER_SPLIT_UDP, >>> the packet consists of MAC_IP_UDP_PAYLOAD will be split like following: >>> seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 >> >> If we set rte_eth_rxseg_split::proto = RTE_ETH_RX_HEADER_SPLIT_UDP and >> rte_eth_rxseg_split.offset = 2, What will be the content for seg0, Will it be, >> - offset as Starts atUDP Header >> - size of segment as MAX(size of UDP header + 2, 128(as seg 1 start from128). >> Right? If not, Please describe > > Proto defines the location in packet for split. > Offset defines data buffer from beginning of mbuf data buffer, it can be zero. > With proto and offset configured, packets received will be split into two segments. > > So in this configuration, the seg0 content is UDP header, the seg1 content is the payload. > Size of seg0 is size of UDP header, size of seg1 is size of payload. > rte_eth_rxseg_split.offset = 2/128 decides the mbuf offset, rather than segment size. Above discussion proves that definition of the struct rte_eth_rxseg_split is misleading. It is hard to catch from naming that length defines a maximum data amount to be copied, but office is a an offset in destination mbuf. The structure is still experimental and I think we should improve naming: offset -> mbuf_offset? > >> >> Also, I don't think we need duplate >> rte_eth_rx_header_split_protocol_type instead we can reuse existing >> RTE_PTYPE_* flags. > > That's a good idea. Yes, I can use the RTE_PTYPE_* here. My only > concern is the 32-bits RTE_PTYPE_* will run out of the 32-bits reserved fields. > If this proposal is agreed, I will use RTE_PTYPE_* instead of rte_eth_rx_header_split_protocol_type. > > Best Regards, > Xuan > >> >> >>> seg1 - payload @ 128 in mbuf from pool1 >>> >>> The memory attributes for the split parts may differ either - for >>> example the mempool0 and mempool1 belong to dpdk memory and >> external >>> memory, respectively.