From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7B056A0032; Thu, 14 Jul 2022 15:25:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0C68242B73; Thu, 14 Jul 2022 15:25:34 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 57F6B42B6D for <dev@dpdk.org>; Thu, 14 Jul 2022 15:25:32 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AAF735C014D; Thu, 14 Jul 2022 09:25:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 14 Jul 2022 09:25:30 -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=fm3; t=1657805130; x= 1657891530; bh=BfMLph6XlGZ2BELUrNFDxZjCHqcrdBsjex5Ym1wNsNw=; b=P ZzaLCt+tcFJ/Qj40pH0HcvEH2UoN7Qk1HsjDO0Pb+VyyYHSgHD//Q2GDR9PQ7jCj BV+1zo5Pyua6SkVQC6YLqBhdViB0VWJfyYOnWwYW+QRoRqc29CyFaNCjMtF1oKtw hrK70WayB0l68MNXD3FyjnTV0iXSv9JnHTFuRljikYl+JhKpEeaRUPweFsTDPLSc D6CPHWSRSDTQ7Qn8gWp6OpywZ5GDLasS0HNiLGBjy62RN5luGQXgnNK5xQ1Klj0Y ASPeVMzA7tJpWIDYyemx+MpteT5HZk2ONAp1qgA7VHGjueUgH4YvoPFNIHDnB0bg 5wWsgtnnodEQOntUF8Kcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id: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=fm3; t=1657805130; x= 1657891530; bh=BfMLph6XlGZ2BELUrNFDxZjCHqcrdBsjex5Ym1wNsNw=; b=o Km48LLeNF8J40e6clkNFsLwJ3Ckr/xkJE5CjXDmfbPRWDW71k67voQBOThVfECOn l+bR0ZDlNE+S1SCcFq5DM0bOWUH91pDs1ZrecGjT3KAPgaBktxZ3jk/BxFkJiolC HuGfswT+8qcbdlkOHVA2WX4vcbJEwZYoZ3gmDN1lXk7RaQaLp37k/Lw4P36PEVyw fI8l16NXjFdVSvJJOYEEPZRfR+k+1Qd8XjYlph2DnCNOc1BzkK7d3rJQa+AcMM8o aUdX5NQVabwGEl3MfYu9ZkbPVQftG754t8cAHfbcbG5HYaWnt7VD3M+uFSC8BUXD L2Ezy64c1tbxwkGPNi3Lw== X-ME-Sender: <xms:SRnQYnW2suhDOlUHn31edrNqty3IbOq4lUycwJGodHVvb6QpqPq9Eg> <xme:SRnQYvnp1pVRy1ZLuMCwBt9BtHfkneZHcIi8YnE56jR91yQloOEHsV91QWbPWheR7 epo8nIb_16VJqdJQA> X-ME-Received: <xmr:SRnQYjato3mpWG-MXlb4ULo9X-bYSs8iQCwvn481vutpBVLqcPlYrjvmhAnyTXCjYobjrro9JhtlQr2rhh-mNYcLvw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejledgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeejjefffffgffekfefflefgkeelteejffelledugefhheelffet heevudffudfgvdenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: <xmx:SRnQYiWw-p4CvK2yrgd1YAcShOQOfqNZb0lgPatPQM0dnFVI-EGWIw> <xmx:SRnQYhkCXp8KNfhw9zFs9hiP5IezfAtPFIkaGeH29RVInUIwaOrLiw> <xmx:SRnQYvf2224VZatqSO6Ck2K549yp89PK6jny_nzwm-PQI8_xccSgHQ> <xmx:ShnQYqdMnRYnBx8-zcFN38mdxu2fG35RXIJ4llLeAQXWDVCdLnkLdw> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Jul 2022 09:25:28 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Ding, Xuan" <xuan.ding@intel.com>, "andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>, "ferruh.yigit@xilinx.com" <ferruh.yigit@xilinx.com> Cc: "mdr@ashroe.eu" <mdr@ashroe.eu>, "dev@dpdk.org" <dev@dpdk.org>, "stephen@networkplumber.org" <stephen@networkplumber.org>, "mb@smartsharesystems.com" <mb@smartsharesystems.com>, "dev@dpdk.org" <dev@dpdk.org>, "Zhang, Qi Z" <qi.z.zhang@intel.com>, "asekhar@marvell.com" <asekhar@marvell.com>, "pbhagavatula@marvell.com" <pbhagavatula@marvell.com>, "grive@u256.net" <grive@u256.net> Subject: Re: [PATCH] doc: announce header split deprecation Date: Thu, 14 Jul 2022 15:25:25 +0200 Message-ID: <5613126.F5Vx1aKkY9@thomas> In-Reply-To: <BN9PR11MB5513C51A807651D2878DC3FCE7889@BN9PR11MB5513.namprd11.prod.outlook.com> References: <20220523142016.44451-1-xuan.ding@intel.com> <6226385.mzcYPaeBD7@thomas> <BN9PR11MB5513C51A807651D2878DC3FCE7889@BN9PR11MB5513.namprd11.prod.outlook.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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 14/07/2022 14:54, Ding, Xuan: > Hi, > > From: Thomas Monjalon <thomas@monjalon.net> > > 14/07/2022 07:50, Ding, Xuan: > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > 23/05/2022 16:20, xuan.ding@intel.com: > > > > > From: Xuan Ding <xuan.ding@intel.com> > > > > > > > > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT offload was introduced some > > time > > > > ago > > > > > to substitute bit-field header_split in struct rte_eth_rxmode. It > > > > > allows to enable header split offload with the header size > > > > > controlled using split_hdr_size in the same structure. > > > > > > > > > > Right now, no single PMD actually supports > > > > > RTE_ETH_RX_OFFLOAD_HEADER_SPLIT with above definition. Many > > > > > examples and test apps initialize the field to 0 explicitly. The > > > > > most of drivers simply ignore split_hdr_size since the offload is > > > > > not advertised, but > > > > some double-check that its value is 0. > > > > > > > > > > So the RTE_ETH_RX_OFFLOAD_HEADER_SPLIT and split_header_size > > field > > > > > will be removed in DPDK 22.11. > > > > > > > > > > Signed-off-by: Xuan Ding <xuan.ding@intel.com> > > > > > --- > > > > > doc/guides/rel_notes/deprecation.rst | 4 ++++ > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > > b/doc/guides/rel_notes/deprecation.rst > > > > > index 4e5b23c53d..b8114f29ed 100644 > > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > > @@ -125,3 +125,7 @@ Deprecation Notices > > > > > applications should be updated to use the ``dmadev`` library instead, > > > > > with the underlying HW-functionality being provided by the ``ioat`` or > > > > > ``idxd`` dma drivers > > > > > + > > > > > +* ethdev: After bit-field header split was removed, the > > > > > +``RTE_ETH_RX_OFFLOAD_HEADER_SPLIT`` > > > > > +offload and the ``split_hdr_size`` field in structure > > > > > +``rte_eth_rxmode`` to enable header split offload are not > > > > > +supported in any > > > > PMDs. They will be removed in DPDK 22.11. > > > > > > > > It would have been good to talk about rte_eth_rxseg_split which is > > > > similar and configured per-queue. > > > > > > Thanks for your suggestion. > > > > > > But I'm a little confused, are you referring that I need to involve protocol > > based buffer split? > > > About the deprecation of header split, I haven't realized its connection to > > rte_eth_rxseg_split. > > > > What??? > > In old versions of your patch "ethdev: introduce protocol type based header > > split" > > you wrote: > > " > > 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. > > " > > It has a long history... > It was corrected in v4 that RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is used to enable header > split offload with the header size controlled using "split_hdr_size". > But no single PMD actually supports RTE_ETH_RX_OFFLOAD_HEADER_SPLIT for this purpose. > So we finally decide to deprecate this flag. > > http://patchwork.dpdk.org/project/dpdk/patch/20220402104109.472078-2-wenxuanx.wu@intel.com/ > > In following series, I use RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT instead. It is for multi-segments packet > split. And it still needs a "proto_hdr" field in rte_eth_rxmode to configure split location. I know this history because I was the one asking you to deprecate this. But it seems you didn't get the big picture. > > > Currently there are 2 acks, add more PMD maintainers to help review > > > this deprecation notice for header split, thanks a lot! > > > > I cannot say my feeling strong enough. > > So IMO the deprecation for header split is not relevant with buffer split. But we can still clean the code. > Hope it make things clearer. They are almost the same features. So when deprecating one, it is important to mention what remains. If needed RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT can still be used and it is configured per-queue, while RTE_ETH_RX_OFFLOAD_HEADER_SPLIT was configurable per-port. Andrew, Ferruh, do you agree to improve this deprecation notice by adding above information?