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 DF849A054A; Thu, 26 May 2022 16:58:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8016340151; Thu, 26 May 2022 16:58:58 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 23F5B40150 for ; Thu, 26 May 2022 16:58:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653577137; x=1685113137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7KK45Lb0bgnmx0ClfKwli+MRmwW0DyGiA48jSiEEy+4=; b=QQKRz2G6/vsI25t1b8MwV9I/nMQeNHWdCgJF7R4noxSH7fq0vmE38Rnl 79pWu9Xl6vrC7qWwdsts8CgHa8SmTl8F6V5UwKhLj92DDWn1+IEba6gwn FKQwqEG0Wf1MYn8krGasvHyn0SsG0grHSDuKE/tR7jQgIrqtQP9Odddrh j5DgSDpA7vHrgGU5CezHEsNkk6pGM/0D293Y0WmSsXFRAYt6TlTD7F5q7 m/rhr/+GYaXlMPz0BPyfXYPcw8r7tMJ2Y6MA7U1wzPjhUhDsT71MaHtC8 GCuOYHAWfTdeVk/Jro9kQZN5n3jE0rWTD00mzJF6hGoOptNnbrosyECcX w==; X-IronPort-AV: E=McAfee;i="6400,9594,10359"; a="274286321" X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="274286321" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 07:58:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="609732905" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orsmga001.jf.intel.com with ESMTP; 26 May 2022 07:58:55 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 26 May 2022 07:58:55 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Thu, 26 May 2022 07:58:55 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Thu, 26 May 2022 07:58:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c74KSUcirOq0HAGbrsVh7ko1hu9t2PVIM+phQQRMP8fLUffsIvFtncmSDXHy+96BjIg+YeMl8AjmAzydeSFw/++XJ62S0GUDD1PRmRG1jI26CA1BxuNFTFJMXw9Yr2lgSmhGAH4BkuRiDqvzMtWAEhFE+rIlY2GQRkQ8fvHB9jZcDLI/8cNE7w3mBItcIKm5uW6UDg+O2LDG3paOlkXhMHXT5ZnccAhYa1dQOrOrb9uiLSwMGQByAb4gqTxpX2Ll76SqB4Z3WpzsXggVvTPC/V0AfbFNDCvM2DAQvU5EB/1dyFZ/bz/bPtsRf+DMAYhE4PUwk46GGvJ0qqBOYgWzdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4fxExHk4DE79Nph5jb/mKMSzCVkUJULsFUeVp6qIy9A=; b=n2o7o1gAE08rRa/4eTZMGmZnJIJX47dcn8HCjR0aMp3zSQccsz2glJvTnRQq/WdFBjdBgIb1dY4/Pk60J7wZP/9TAzziTZ7OWxIEFhtweFrI8PFEj4VoTK2GFXCnJsX44a57ZzlJMJWvAzKBqCUinWpDO2lZjdzyXneepWr/hJKZC6UxpT4eJmOgCJuQtYydTt66g/w57XscWIHZDO0HJT28F25jfv/beB6wCBlkUQuSibeWLg2JxbybY0t1ECW2/z/WKBt8y4BhSnKArkxDDvDUuoJnCy3JJG6U2XpQJZc5RXclF8SuTuFalKLQsNy6IDyBdlYHjPTxhbGo+el0Xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from BN9PR11MB5513.namprd11.prod.outlook.com (2603:10b6:408:102::11) by DM6PR11MB3881.namprd11.prod.outlook.com (2603:10b6:5:199::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.17; Thu, 26 May 2022 14:58:53 +0000 Received: from BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::31c6:2ec8:2f71:42da]) by BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::31c6:2ec8:2f71:42da%2]) with mapi id 15.20.5293.013; Thu, 26 May 2022 14:58:52 +0000 From: "Ding, Xuan" To: "Ding, Xuan" , Thomas Monjalon , "Wang, YuanX" , "Wu, WenxuanX" 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" , "mb@smartsharesystems.com" , "viacheslavo@nvidia.com" , "Yu, Ping" Subject: RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split Thread-Topic: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split Thread-Index: AQHYWWHjXWRAXZeomU69gwCsfILTOK0jsrsAgAJIs3CAC3F/wA== Date: Thu, 26 May 2022 14:58:52 +0000 Message-ID: References: <20220402104109.472078-2-wenxuanx.wu@intel.com> <20220426111338.1074785-1-wenxuanx.wu@intel.com> <20220426111338.1074785-2-wenxuanx.wu@intel.com> <13015742.y0N7aAr316@thomas> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.500.17 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 04c57174-3eaf-4ef2-db84-08da3f283fd5 x-ms-traffictypediagnostic: DM6PR11MB3881:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y/GaTbi4VtCVsa2Z2IYds0FSaA/fyOXrsfxjE01+yjvrzIJEnaUCN2ArqVpv60KqZ6u/XniNBo3Cq21/vDUSI76aP06vVOxHnRkgd2tSy8y8BQIB3IpfFs6+nLT0ClUqpQG0LBIrw3ErNNUBVPPC0qhK877rcQBfNftM5dv3wVgF1ISvD6yg7kxnNkaiOO2U48V5t4csjhlZTBTqA3ywKAWotUG7eEUN8krUTZk63PKpJMGZpPiv39UsnxZuQOXFYDNpw2B2ztARd6W9B6YU2ItGwuDDWJwDgo8+Xa1kWmlQHD+hahWJVfcIYlyo60Lx5+bXowdD1tjMx09Zz4IuJRMpdSg5aMU9qNXxXUwLJSFgQfFrXuBXU0EmD0zLnuOU+IhVXopxkLHM3qALCpM3Gic7/LIPHrlNTZJW3XUc6NkjcuYpBTR8jxrkFnGWsqkvFiI83c60UinMH8K9I2uDdhLowaqoHIUHbrcn/R5KI0LUr8hosOb9qlmUIJ6ZwdZU6Nr7KJsgexri6UrMYZEhkfN9ZjbWIDg5GPVQzjl4R4SMbAAQxiZVDfE6Nvhel5fV+vzf/93LA1NKoca5BDb0WpoREf/8ZXp6Zz8Ae3i9ydgo+bBAXKfAY91EJV9vmNnOmjmcgklIN5g0MVTpfTacq+Ejku5AhmJgbtcIBbgyhUucM6CpI80ApQiz3/1E2Ej6I7y7zoV5NazR+PTnwm+gyg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5513.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38070700005)(30864003)(26005)(9686003)(5660300002)(6636002)(4326008)(8676002)(107886003)(64756008)(66446008)(66476007)(66556008)(52536014)(66946007)(76116006)(54906003)(38100700002)(316002)(186003)(508600001)(8936002)(82960400001)(83380400001)(110136005)(122000001)(71200400001)(55016003)(86362001)(2906002)(7696005)(6506007)(33656002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tFQFlOCnPQr7jtg9cKhTrQZ4rW9gZxr+viJDYIyz1IFNxXz8x2QbVlpapRgw?= =?us-ascii?Q?uonOQqWs854L/9+XUfD2OttukvUUtc0iDOvCK63vY/AfmogsDhwNZAHn3nJR?= =?us-ascii?Q?u5A9K41GCWXFpu5NytQJHZeZZ2oYaT9W/ThFeN2WIqDVh10T909e2yX8oihs?= =?us-ascii?Q?0Yuyz0qrNTJkoHuw/RBg0jpwuJf9E1on7dI//e7w6xKPyM7ofMg2vA8XeM7W?= =?us-ascii?Q?/HEiEUX+sN7dxOp8pY+3TCioLvhkzOaOKe+PlqvY3mpobIZrqC7cOZ7Ag7B3?= =?us-ascii?Q?c9Wz+dj/8pKzWKBB+0NW4Ey1MntRjQDBazAG8+SoCLHr3Kjmyq8GuIT452LL?= =?us-ascii?Q?FTYsZyq+fZOep1NngX2t96zVrnZrYOkI8jffP4fkN74qEhYT1OuH5PnRTK20?= =?us-ascii?Q?uh2G7iPjsGn199gDIQFc/6UKLes1aZ+zSw4R0wGCNwP21aWoeoMrdvUOBcTa?= =?us-ascii?Q?dXVX68A030r0RZ5/QSlHcJygO/bg0EemrEyUpfj9oRhMfg8C5+9uutkz97oj?= =?us-ascii?Q?FWLFTEIMFkwUVVMtnPBwp7bqmDANGWTZYVn7S1AcAUZoLu0uDgq40R705I3c?= =?us-ascii?Q?aGYDUDVBDwjl9M2U8mYuYiSO6ktupHnNGg+71zpPKxRq1T3YO0ylTFWB3+dx?= =?us-ascii?Q?shHEIDQYRYFbfwsJt+eFkHvoxUWKRxNNcC+I884Lt0gFnswJZq+EtrhZVs8D?= =?us-ascii?Q?1tGuRquZ5c6PE1lOQZUgifsWXi8kfE1Zp/i/JTWmtieoAX8Ds7oZLeNxiwDp?= =?us-ascii?Q?36ql4uPkogRuHkO0SvnoIRUoprU9qLjGcTbxFkql56wex2Ec1l1ViXdlr79f?= =?us-ascii?Q?Amzyz6Z9YcdnMIHAnqpGmidGdlGOxokDcBFQyQNM6rbiq7n7efQUVJu40ySm?= =?us-ascii?Q?oKJWXI7w0Pf1vgwgMqpDNoRiU328TFnv16mGN6c6/PDlASIQ4Ut783fj8ovY?= =?us-ascii?Q?UxUfjYI90th0+il/WuBZOgyO52re75E1+8FVkpNGbmcDRmRl7R2WjbI0JQS4?= =?us-ascii?Q?SpHi2hWxWb+f7OVUkV+N0hIPchweEZ2iFmA6Jga+K8rXLmf/ZLeqolhJPyjQ?= =?us-ascii?Q?Nbpg8/+J6rDHY+XXfysPDLxuD4XfJd/9If88YjS5CGvYEKzYE0YsGdFFUFp4?= =?us-ascii?Q?oVhVLnp0cO4Dh1Rk4oGMEX6c1/V3WWuogDHsfN3lH6+RWa4P0drkKTipJ0uj?= =?us-ascii?Q?1VTm/JWLP0RSMV8trbX8YlNT92z4VIg5ZVrqd1v63cKP56j3Nuk9XSlav7vK?= =?us-ascii?Q?ipM3CKBxNx3LoVEtlSLfhcGSDBR6THCEDBwihIOhMiIaByttMhDzM+PpJNR3?= =?us-ascii?Q?WdF/fP0v5XQSD4GBZ21wyRVy+jZCiblwD7pVQZ1QRFwR+gwhJ1Z/68POdbsv?= =?us-ascii?Q?dq9H74tKlCiqqlCes7939J0+LbmqKvhm904szX1QGtoUSiWrbaQom33UUPTw?= =?us-ascii?Q?axswLtxuLuSzYUAEtSzpo2RcfeqkRqnaE0nAQ9UsUGCdfmAQG0d3lotqr4vl?= =?us-ascii?Q?gAd269rjw5g7lIhFX6p1sKKFyF9ImCgI8ssdQtgx9kEjLpil3xqzyzx/00wV?= =?us-ascii?Q?wikNvWNnxPJlMk7hyqC5hUnxqynkwXzd2XW7OmoQEUPRol2ku7wiVpEibbQl?= =?us-ascii?Q?hTR7aWdoetsgYkTEjGevHPADSCRrcoa62sEu8FWJoqmbCeTxhkEjxTZaqr+t?= =?us-ascii?Q?SoDQM/xtS9kBiVptenod7opj8vi4SIwcp/81VMMUFa9Ty39EtUWY6RAOPvDA?= =?us-ascii?Q?B9O6ShDeTA=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5513.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04c57174-3eaf-4ef2-db84-08da3f283fd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2022 14:58:52.8255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1mLhhfKI6qzWo6Jid5or2ymyHt8xo2QvIkQyoEua1AtvqXSc0gdJENXmBVaetz0d4H5RTpfOf2mF5hNifDfuUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3881 X-OriginatorOrg: intel.com 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 Hi, > -----Original Message----- > From: Ding, Xuan > Sent: Thursday, May 19, 2022 10:40 PM > To: Thomas Monjalon ; Wang, YuanX > ; Wu, WenxuanX > 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; mb@smartsharesystems.com; > viacheslavo@nvidia.com; Yu, Ping > Subject: RE: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buf= fer > split >=20 > Hi Thomas, >=20 > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Wednesday, May 18, 2022 5:12 AM > > To: Ding, Xuan ; Wang, YuanX > > ; Wu, WenxuanX > > 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; mb@smartsharesystems.com; > > viacheslavo@nvidia.com; Yu, Ping > > Subject: Re: [PATCH v5 1/4] lib/ethdev: introduce protocol type based > > buffer split > > > > Hello, > > > > It seems you didn't try to address my main comment on v4: > > " > > Before doing anything, the first patch of this series should make the > > current status clearer. > > Example, this line does not explain what it does: > > uint16_t split_hdr_size; /**< hdr buf size (header_split > > enabled).*/ And header_split has been removed in ab3ce1e0c193 > > ("ethdev: remove old offload API") > > > > If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a > comment > > to start a deprecation. > > " >=20 > Thank you for the detailed review. >=20 > First of all, I agree that header split should be deprecated. > Since it is unrelated with buffer split, I was planning to send the depre= cation > notice in 22.07 sometime later and start the deprecation in 22.11. >=20 > If you think it should be the first step, I will send the deprecation not= ice first. >=20 > > > > Also the comment from Andrew about removing limitation to 2 packets is > > not addressed. >=20 > Secondly, it is said that the protocol based buffer split will divide the= packet > into two segments. > Because I thought it will only be used in the split between header and > payload. >=20 > In fact, protocol based buffer split can support multi-segment split. > That is to say, like length-based buffer split, we define a series of pro= tos, as > the split point of protocol based buffer split. And this series of protos= , like > lengths, indicate the split location. >=20 > For example, a packet consists of MAC/IPV4/UDP/payload. > If we define the buffer split proto with IPV4, and UDP, the packet will b= e split > into three segments: > seg0: MAC and IPV4 header, 34 bytes > seg1: UDP header, 8 bytes > seg2: Payload, the actual payload size >=20 > What do you think of this design? >=20 > > > > All the part about the protocols capability is missing here. >=20 > Yes, I missed the protocols capability with RTE_PTYPE* now. > I will update the doc with supported protocol capability in v6. >=20 > > > > It is not encouraging. > > > > 26/04/2022 13:13, wenxuanx.wu@intel.com: > > > From: Wenxuan Wu > > > > > > Protocol based buffer split consists of splitting a received packet > > > into two separate regions based on its content. The split happens > > > after the packet protocol header and before the packet payload. > > > Splitting is usually between the packet protocol 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 sp= lit. > > > protocol split is based on buffer split, configuring length of > > > buffer split is not suitable for NICs that do split based on protocol= types. > > > > Why? Is it impossible to support length split on Intel NIC? >=20 > Yes, our NIC supports split based on protocol types. And I think there ar= e > other vendors too. > The existence of tunneling results in the composition of a packet is vari= ous. > Given a changeable length, it is impossible to tell the driver a fixed pr= otocol > type. >=20 > > > > > Because tunneling makes the conversion from length to protocol type > > > impossible. > > > > This is not a HW issue. > > I agree on the need but that a different usage than length split. >=20 > I think the new usage can solve this problem, so that length split and pr= oto > split can have the same result. >=20 > > > > > This patch extends the current buffer split to support protocol and > > > offset based buffer split. A new proto field is introduced in the > > > rte_eth_rxseg_split structure reserved field to specify header > > > protocol type. With Rx queue offload > > RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT > > > enabled and corresponding protocol type configured. PMD will split > > > the > > ingress packets into two separate regions. > > > Currently, both inner and outer L2/L3/L4 level protocol based buffer > > > split can be supported. > > > > > > For example, let's suppose we configured the Rx queue with the > > > following segments: > > > seg0 - pool0, off0=3D2B > > > seg1 - pool1, off1=3D128B > > > > > > With protocol split type configured with RTE_PTYPE_L4_UDP. The > > > packet consists of MAC_IP_UDP_PAYLOAD will be splitted like following= : > > > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from > pool0 > > > seg1 - payload @ 128 in mbuf from pool1 > > > > Not clear what is the calculation. >=20 > The previous usage of protocol based split is the split between header an= d > payload. > Here for a packet composed of MAC_IP_UDP_PAYLOAD, with protocol split > type RTE_PTYPE_L4_UDP configured, it means split between the UDP header > and payload. > In length configuration, the proto =3D RTE_PTYPE_L4_UDP means length =3D = 42B. >=20 > > > > > The memory attributes for the split parts may differ either - for > > > example the mempool0 and mempool1 belong to dpdk memory and > > external > > > memory, respectively. > > > > > > Signed-off-by: Xuan Ding > > > Signed-off-by: Yuan Wang > > > Signed-off-by: Wenxuan Wu > > > Reviewed-by: Qi Zhang > > > --- > > > lib/ethdev/rte_ethdev.c | 36 +++++++++++++++++++++++++++++------- > > > lib/ethdev/rte_ethdev.h | 15 ++++++++++++++- > > > 2 files changed, 43 insertions(+), 8 deletions(-) > > > > > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > > > 29a3d80466..1a2bc172ab 100644 > > > --- a/lib/ethdev/rte_ethdev.c > > > +++ b/lib/ethdev/rte_ethdev.c > > > @@ -1661,6 +1661,7 @@ rte_eth_rx_queue_check_split(const struct > > rte_eth_rxseg_split *rx_seg, > > > struct rte_mempool *mpl =3D rx_seg[seg_idx].mp; > > > uint32_t length =3D rx_seg[seg_idx].length; > > > uint32_t offset =3D rx_seg[seg_idx].offset; > > > + uint32_t proto =3D rx_seg[seg_idx].proto; > > > > > > if (mpl =3D=3D NULL) { > > > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); > > @@ -1694,13 > > > +1695,34 @@ rte_eth_rx_queue_check_split(const struct > > rte_eth_rxseg_split *rx_seg, > > > } > > > offset +=3D seg_idx !=3D 0 ? 0 : RTE_PKTMBUF_HEADROOM; > > > *mbp_buf_size =3D rte_pktmbuf_data_room_size(mpl); > > > - length =3D length !=3D 0 ? length : *mbp_buf_size; > > > - if (*mbp_buf_size < length + offset) { > > > - RTE_ETHDEV_LOG(ERR, > > > - "%s mbuf_data_room_size %u < %u > > (segment length=3D%u + segment offset=3D%u)\n", > > > - mpl->name, *mbp_buf_size, > > > - length + offset, length, offset); > > > - return -EINVAL; > > > + if (proto =3D=3D 0) { > > > > Add a comment here, /* split at fixed length */ >=20 > Thanks for the suggestion, will add it in next version. >=20 > > > > > + length =3D length !=3D 0 ? length : *mbp_buf_size; > > > + if (*mbp_buf_size < length + offset) { > > > + RTE_ETHDEV_LOG(ERR, > > > + "%s mbuf_data_room_size %u < %u > > (segment length=3D%u + segment offset=3D%u)\n", > > > + mpl->name, *mbp_buf_size, > > > + length + offset, length, offset); > > > + return -EINVAL; > > > + } > > > + } else { > > > > Add a comment here, /* split after specified protocol header */ >=20 > Thanks for the suggestion, will add it in next version. >=20 > > > > > + /* Ensure n_seg is 2 in protocol based buffer split. */ > > > + if (n_seg !=3D 2) { > > > > (should be a space, not a tab before brace) >=20 > Get it. >=20 > > > > Why do you limit the feature to 2 segments only? >=20 > Please see the new usage explained above. >=20 > > > > > + RTE_ETHDEV_LOG(ERR, "number of buffer > > split protocol segments should be 2.\n"); > > > + return -EINVAL; > > > + } > > > + /* Length and protocol are exclusive here, so make > > sure length is 0 in protocol > > > + based buffer split. */ > > > + if (length !=3D 0) { > > > + RTE_ETHDEV_LOG(ERR, "segment length > > should be set to zero in buffer split\n"); > > > + return -EINVAL; > > > + } > > > + if (*mbp_buf_size < offset) { > > > + RTE_ETHDEV_LOG(ERR, > > > + "%s > > mbuf_data_room_size %u < %u segment offset)\n", > > > + mpl->name, *mbp_buf_size, > > > + offset); > > > + return -EINVAL; > > [...] > > > + * - The proto in the elements defines the split position of receive= d > packets. > > > + * > > > * - If the length in the segment description element is zero > > > * the actual buffer size will be deduced from the appropriate > > > * memory pool properties. > > > @@ -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 should not be configured in length split. Zero de= fault. > > > + * > > > + * - Protocol based buffer split: > > > + * - mp, offset, proto should be configured. > > > + * - The length should not be configured in protocol split. Zero= default. > > > > What means "Zero default"? > > You should just ignore the non relevant field. >=20 > Yes, you are right, the none relevant field should be just ignored. > I will update the doc in v6. Sorry for replying myself. After consideration, I found it is hard to just ignore the non-relevant fie= ld. Because when length and proto both exist, it is hard to decide whether it i= s length based buffer split or protocol based buffer split, which affects the check in rte_eth_rx_queue_check_split(). So I would like to keep the current design in v6. When choosing one mode of buffer split, the non-relevant field should not be configured. Hope to get your feedbacks. :) Regards, Xuan >=20 > > > > > 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 buffe= r. > > */ > > > - uint32_t reserved; /**< Reserved field. */ > > > > How do you manage ABI compatibility? > > Was the reserved field initialized to 0 in previous versions? >=20 > I think we reached an agreement in RFC v1. There is no document for the > reserved field in the previous release. And it is always initialized to z= ero in > real cases. > And now splitting based on fixed length and protocol header parsing is > exclusive, we can ignore the none relevant field. >=20 > > > > > + uint32_t proto; /**< Protocol of buffer split, determines protocol > > > +split point. */ > > > > What are the values for "proto"? >=20 > Yes, I missed the protocol capability here, will fix it in v6. >=20 > > > > > @@ -1664,6 +1676,7 @@ struct rte_eth_conf { > > > RTE_ETH_RX_OFFLOAD_QINQ_STRIP) #define > > DEV_RX_OFFLOAD_VLAN > > > RTE_DEPRECATED(DEV_RX_OFFLOAD_VLAN) > RTE_ETH_RX_OFFLOAD_VLAN > > > > > > + > > > > It looks to be an useless change. >=20 > Thanks for the catch, will fix it in next version. >=20 > Thanks again for your time. >=20 > Regards, > Xuan >=20 > > > > > /* > > > * If new Rx offload capabilities are defined, they also must be > > > * mentioned in rte_rx_offload_names in rte_ethdev.c file. > > > > > > > > > > >