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 B4AEAA0093; Thu, 21 Apr 2022 12:36:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5663540042; Thu, 21 Apr 2022 12:36:49 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 3277D40040 for ; Thu, 21 Apr 2022 12:36:48 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9CE4A320209A; Thu, 21 Apr 2022 06:36:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 21 Apr 2022 06:36:47 -0400 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=fm1; t=1650537405; x= 1650623805; bh=bEB+2V/yLOR6eWl83EBWQd2wsDN2nK1/QRGxDBP2yps=; b=i UGIKcmR1PTHXjzNT5TxIlVw1zPDSgRNMBudO4oPqs8Z7l3cS03EsPCQln4IP1aps DkYuj9mzukciXnfOdjSDYtqVJ/x1ZWJEi33F6JTvva4fSJti322sWywdTAxVw/Q0 KMXnOHTUE67mmZZ7b05cxBGjXL5+hHgCbECIG30nhjKaUdht7qAeivnS2cCSvRt2 IWdNaTEbo/ZUpI7d/1/Uq7G1qBTtHPNzkJrblZqMow4LsbT0VYMjFk+qMJPMfZoR 8+O1SIbuJ0pJ2dTjk5tR5JLkk5MuCodNkXo9vG9eeWSwcdSMLDsHxEYkDYz+J3YN WuaHgv1Km/f5yQ7UB65+Q== 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=fm1; t=1650537405; x=1650623805; bh=bEB+2V/yLOR6e Wl83EBWQd2wsDN2nK1/QRGxDBP2yps=; b=CEY1Idry/EVx2Q4rsbuHtvxB0PZpj vVCkqyPApND8XsPBywq4K+DsRPiyvZnpABmHVvi8CDbss8ejoZJkMBAcFX1DSjo+ rPM1r4mBBeuN6h5RhwU81NvjtKDqSPpH+eAxwzBf3I/L0iz0n9GtPW62l3vUR3aP OsDsfNb0k2jsK0XuNR4NeC4SUUUDdbkkNgBi1imvc9sIPNPuIIKLFzJzCoxzhTHr uKwu3Rm0hM9rUJTgTEp7qSsR6AHX6kuyJbIEcY0fgDUSKYFvmVBJEB1cX5p6wp5W 0pZA+42DUaFs079bWFZEAWH/JhQ75Fo38gqDiCAdvtvFZbpyL+Co1UoUQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrtddvgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Apr 2022 06:36:43 -0400 (EDT) From: Thomas Monjalon To: "Ding, Xuan" , Jerin Jacob , "Wu, WenxuanX" , dev@dpdk.org Cc: "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Zhang, Qi Z" , dpdk-dev , Stephen Hemminger , Morten =?ISO-8859-1?Q?Br=F8rup?= , Viacheslav Ovsiienko , "Yu, Ping" , "Wang, YuanX" , Andrew Rybchenko Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split Date: Thu, 21 Apr 2022 12:36:41 +0200 Message-ID: <3484220.R56niFO833@thomas> In-Reply-To: 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 20/04/2022 16:39, Andrew Rybchenko: > On 4/12/22 19:40, Ding, Xuan wrote: > > From: Jerin Jacob > >> 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? I agree it is confusing. mbuf_offset could be a better name. length could be renamed as well. Is data_length better? But the most important is to have a clear description in the doxygen comment of the field. We must specify what is the starting point and the "end" for those fields. > >> 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. Yes I think RTE_PTYPE_* is appropriate.