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 912F4A0032; Mon, 11 Jul 2022 12:13:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C71A40223; Mon, 11 Jul 2022 12:13:02 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 7C9504021F for ; Mon, 11 Jul 2022 12:13:00 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 694CB5C00E1; Mon, 11 Jul 2022 06:12:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 11 Jul 2022 06:12:57 -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=1657534377; x= 1657620777; bh=uGGbRHDrntTVqF+obXSv3p1L6ehPZjfXTwlYwlxswBs=; b=O wb8NeWFERuOrH1u1KCXQin3aa6znPXXZWvfgTAwYvS7P0OmlDWclu2y9Q9K1do8E q4gZAc1/9IsweoUEYaO8Eo1SOIK+ZtqA2TfiYzyiTHM+zu6kU540Ir4e8NNnkIsg jWd8Ofbvw4Fwr7nsi4lKNvqQlMo+uTuWAB5yLFk/jj9YbXGeD3yGzXvUlhHdLr0X WRSHNZpTNarD0YoHMiHpcSGK5IUZrpK8oPIMnOcO/jBW2zLGJSrAXjTmwwrB69su KGMp8MXlPWqELruogrb0/kBI8dfWSvnP1otNQ2eoSkyfDz6y1dxNxbWDfRICDul6 C4g9TNOP+OaraN9dKBEOw== 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=1657534377; x= 1657620777; bh=uGGbRHDrntTVqF+obXSv3p1L6ehPZjfXTwlYwlxswBs=; b=p XnWCbyz5Ay+F2GSqVF+chUhKFMIi32SAArTBqgKdNXjymlv5yX9lsegDU+VWzCKm paQAlDfCHiGfl1GZqY9CNK4uX9W0s+ndGem8ZBgrmzaCNobkqnw/v/GZPNbNyGoU Nhz3PkC2BnD56F3AqxwGu3/sBsI5cRpjpJs37jH1IqKrOLFvBl91AbLZPqZ54LKB Oe1yjmw3lyyjKMYGE3wgljFAVaAj4o74OvGd2FeKkiZklCNT0C49lx4PZzIf0EAY ziHNWh1i8rXOA2GSt7ex81ZTRJy5WjnCYKvyeRZojE0DwAUCVv3EHhjGpN1hsSUz I22+VFFfxmMAK81tvCbdQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejfedgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 11 Jul 2022 06:12:55 -0400 (EDT) From: Thomas Monjalon To: "Wu, WenxuanX" , "Ding, Xuan" Cc: "andrew.rybchenko@oktetlabs.ru" , "Li, Xiaoyun" , "ferruh.yigit@xilinx.com" , "Singh, Aman Deep" , "dev@dpdk.org" , "Zhang, Yuying" , "Zhang, Qi Z" , "jerinjacobk@gmail.com" , "stephen@networkplumber.org" , "Wu, WenxuanX" , "Wang, YuanX" , Ray Kinsella Subject: Re: [PATCH v9 2/4] ethdev: introduce protocol hdr based buffer split Date: Mon, 11 Jul 2022 12:12:53 +0200 Message-ID: <10778763.q1WVWOPYzV@thomas> In-Reply-To: References: <20220303060136.36427-1-xuan.ding@intel.com> <3814226.y1PWrYsiD0@thomas> 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 11/07/2022 11:54, Ding, Xuan: > From: Thomas Monjalon > > 13/06/2022 12:25, wenxuanx.wu@intel.com: > > > --- a/lib/ethdev/rte_ethdev.h > > > +++ b/lib/ethdev/rte_ethdev.h > > > @@ -1176,6 +1176,9 @@ struct rte_eth_txmode { > > > * specified in the first array element, the second buffer, from the > > > * pool in the second element, and so on. > > > * > > > + * - The proto_hdrs in the elements define the split position of > > > + * received packets. > > > + * > > > * - The offsets from the segment description elements specify > > > * the data offset from the buffer beginning except the first mbuf. > > > * The first segment offset is added with RTE_PKTMBUF_HEADROOM. > > > @@ -1197,12 +1200,21 @@ struct rte_eth_txmode { > > > * - pool from the last valid element > > > * - the buffer size from this pool > > > * - zero offset > > > + * > > > + * - Length based buffer split: > > > + * - mp, length, offset should be configured. > > > + * - The proto_hdr field should not be configured. > > > + * > > > + * - Protocol header based buffer split: > > > + * - mp, offset, proto_hdr should be configured. > > > + * - The length field should not be configured. > > > */ > > > struct rte_eth_rxseg_split { > > > struct rte_mempool *mp; /**< Memory pool to allocate segment > > from. */ > > > uint16_t length; /**< Segment data length, configures split point. */ > > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer. > > */ > > > - uint32_t reserved; /**< Reserved field. */ > > > + /**< Supported ptypes mask of a specific pmd, configures split point. > > */ > > > > The doxygen syntax is wrong: remove the "<" which is for post-comment. > > Thanks for your catch. > > > > > > + uint32_t proto_hdr; > > > }; > > > > How do we know it is a length or buffer split? > > Is it based on checking some 0 value? > > Yes, as Andrew suggests, we introduced the API rte_eth_supported_hdrs_get() in v9. > It will report the driver supported protocol headers to be split. > If the API returns ENOTSUP, it means driver supports length based buffer split. > > Of course, no matter what kind of buffer split it is, we need to check > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT first. So you need to talk about RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT in the comment of this struct.