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 812C4A0503; Thu, 19 May 2022 16:40:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 71AC04161A; Thu, 19 May 2022 16:40:31 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 811DF40223 for ; Thu, 19 May 2022 16:40:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652971229; x=1684507229; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PjBBjzZ1wA3IsWTj5Rxh5wl6QKCwaiJumSNEd3haHP8=; b=k3GKPc4s+E/yHApbmlgAyEP9qWwuCaA3lNn/fOio92kVTFdbLgARH8Ar mC9QKm0Gawv1WjKOfD//Z3E3zmljTtmeDop5mEKweKnijZx9YhBE5yrrU U4+2qsyhqu7Rt5nK/wn+h2DjDC0AmiqQeepiVFvAsuxUJzn4uWkzfEnQu XrMsBoKfJHAw3bsbEJX0hzSxVYY4whAJeptUKazCDIsrpaQ2UQqP3Jh9Z Q6X/g81i+sPNGWVjLX4sc/5GuUah1/iaC0OCldrOAuBppUNfY7q9JHv5w TzzWxuNCEiPIyrdEQp5CMNuhzHFwTVzQQ8A6QtVXCqtHmcvmQO3afGI5B g==; X-IronPort-AV: E=McAfee;i="6400,9594,10352"; a="252121296" X-IronPort-AV: E=Sophos;i="5.91,237,1647327600"; d="scan'208";a="252121296" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2022 07:40:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,237,1647327600"; d="scan'208";a="674041114" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga002.fm.intel.com with ESMTP; 19 May 2022 07:40:28 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 19 May 2022 07:40:27 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 19 May 2022 07:40:27 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx612.amr.corp.intel.com (10.22.229.25) 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, 19 May 2022 07:40:27 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Thu, 19 May 2022 07:40:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fvVfKB099xO6gtizhgDTxujdzmPW9btmQ2v0CT2sh8DdSLraE9NszxmCw4EFDYlukdJVVyBMQkzZ4ooXLgd3gh3WCC4WIiz6EN5c/SmXO72STpN+0b6JAjWp077XQe5RbGUXFSHYXLEfm97501RWuzz3eYw56niu925u/SW/0TRax0bgDfJbhhNkCmaAxOu5GhJ0Dd7lS5PZ8rLf+N6PgLga6RjIHOHrYI5tFPMOCTycCNTpCPKxOM9E4sv+oRWL/2XsKBXCiIHX5PyPsNrZLs6VSM+xmytDJD8fYdOA8XxScpUb98JfPKaiX1gUowKdWtNj2thkfE060rAdCn5kag== 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=tM9y4jN9yb0qKpATGWd7TgmgmQELoTPvql0n+B3ZVrE=; b=hnk21nGtbAN7303+PWO4yNH3cCWXWTC5aMv6aAsWeCMy6Lvyw3Aym09pb2TT3ORAE7IGUtaJ9oJxqLLdzN7K87wjHD8I6RZ3Xsusj9tE3obh3HBpcNKqbJUt7DhbF3uYU+wdw39E6Wo2kl9UoTvHUhfMPlidgcveJyHmCJD3OtRrRfO7cImgwWagZIroijRR6O+rX2r9uSQq9qfchcoalDWddu0IWf7yuw3sc7+Rs69Cg9QoImkjIK4P48DpnXVxUa+ykDtDxUyX0KTmnvNoUj6EYbGNE5wZpf+8fcF0R6MdPR6PKIzPB2jOIsS1ohP4Mi0ozZwkwfPEVsqnBQCeCw== 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 DM6PR11MB3355.namprd11.prod.outlook.com (2603:10b6:5:5d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.14; Thu, 19 May 2022 14:40:24 +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.5273.015; Thu, 19 May 2022 14:40:24 +0000 From: "Ding, Xuan" 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 buffer split Thread-Topic: [PATCH v5 1/4] lib/ethdev: introduce protocol type based buffer split Thread-Index: AQHYWWHjXWRAXZeomU69gwCsfILTOK0jsrsAgAJIs3A= Date: Thu, 19 May 2022 14:40:24 +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: <13015742.y0N7aAr316@thomas> 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.401.20 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: 7434ac29-ec03-429c-f709-08da39a58245 x-ms-traffictypediagnostic: DM6PR11MB3355: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: jx5P7sxnirpyYQm5i3lEKETU6I1fqk70zLjTz/RUXDVF2RWQ85+nJ2zvnkogEvPYrhtbv7aWjl+xZ3yoFDMvpbKkOHuMYSBNFF7O1x6Uug0QgGPkqWH+LO2P2nuB5GpJIopT0H/X6aFFQvHrSqehxJnJU5aWjo6KP0QUp+cAbL1Z0IL7cKlaj2Ql+lW5DTvTecqruipC+kdGPg6IkDmW/3HEtqlPvA0+ej2z/rpWk5cGoWkzEJJa7SgHSmyNpM824eDtZ0I+2OygaOXcAYpvW5PC7Scz1pS+fh3/y7y0wBIKH3LhWtw+VKQ54i5jna8xB2j9mbbOhPKBgjdFXrSbo4VITQNuv+H9PsWDzOMz+Yu5uTZvE7Rw6caWsWhRjpZrKPBek0WynSeK6N5Pn4YiEs62hvd8svzwldEs0pfRuwgIMM8oZuzIYqN4Vivpozyn2Oip5KuacsTvjRkN9m0Ucm/agB/R8eDBoXnQFgIQlaK8q+YDHQj/rHqaD+Lp8NnkVzvpoVB0IATJYIANCJMXkc9VEIOpu+NozaBsAVpjKudxuxnZcbNGjbKyfyni1hlyFbeJNEAebgX519F2CGX/qVvkuZFsAhLXhTFYTjSuaFotABMoFFqB0V0IRES2rDNtZWbeDbyhiI4D/gtZJ33S8aRtpqL9Ktmo//7iroOozRv7rou5ahvwXzMofMscHUJh47yknJJkzEj+gGlRaS2YwQ== 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)(107886003)(316002)(71200400001)(8936002)(38070700005)(122000001)(9686003)(54906003)(86362001)(6636002)(30864003)(55016003)(38100700002)(52536014)(508600001)(110136005)(82960400001)(5660300002)(26005)(64756008)(4326008)(33656002)(53546011)(66556008)(66476007)(66446008)(8676002)(2906002)(83380400001)(7696005)(186003)(6506007)(66946007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BFEnnErne9eOzX2431R8A8w3oy/4cT14w8QUJxHY9nOs+Cq/jbGTAYT/IGM3?= =?us-ascii?Q?bPFI9ndKuuPoEZ5quEyBF3Pd/JclNr7I+CMu6COdnUl12qZlDQaFhFCJ0+rj?= =?us-ascii?Q?cn/g16ADZ4+Qi0fKs+BwNmp5wLDgiFEVeEt98fUsh99MZ13yrL67HUX3o5pC?= =?us-ascii?Q?QDn+MGzG2sHl+jQbebBBsQDbIC3Fn+s+DjVzyVRFP6NzecTpFrWEqmn0a9Rh?= =?us-ascii?Q?PHrvMZP/L2knKQaDcQ4OxVixOpaP2ap4g2XjLZVuu2wzIOySQSyUTTXpEbH5?= =?us-ascii?Q?bKq1EYwv1HcLKawzfrjN+aXa4hSsoXoW9iIypkk1rxFqMV63MyU8cJv84jAA?= =?us-ascii?Q?bdpDFXiLkiCdZlDbNIzPeTWUu1HfueR5Z3BCwojkM8aAMa+JWjyLgRaKvFSf?= =?us-ascii?Q?hXSDMcORbVKnbF2zOxRreObZBr7smtVUcJZ+DF/uSQMs/mIXD6YxP8v682H3?= =?us-ascii?Q?oIMWdK7qN8Nftfdu0XNn/GARuZ7/xluqYN+yZ2KfeGdh+qGDKjarfgq8HecU?= =?us-ascii?Q?zwMdgVd3heMXOaoAZ5guq+sxNZpx5ZdDmNLwXY59HWtGgzeYFYSueuTzvzd6?= =?us-ascii?Q?Icg4UCwX2+ReMfX5k4UKRq1Wb51b3hMex7shZD9RVD4FzWpw9A830DZskYE3?= =?us-ascii?Q?tpEKPXQcRz702WmxkVDA4LHNjUfGmye7S7Cfnvfom+YxVp7fIP/LF34n/8V/?= =?us-ascii?Q?y2afAd1FK1YQDXC4XdzoiMvDa3ALMmVX0O57dGsnpBP5lm4AnhBilEzpYDFb?= =?us-ascii?Q?OWO1Z0i1ptzEUlY5jVb+er9LUy1FA9XWLDl+zVDgIPfX0xFaZil4hoBD8dC0?= =?us-ascii?Q?76HhXyZrAzYeYLvgH7QfwXM72VgGjNpc83pKoogdoa4ndZMQPty8XYdVnmS5?= =?us-ascii?Q?lZVlaVtZJ5k2Pq1tInEJyGqBKGLAENpB0bHxO9izWc0eLkt6V6+4xlswqAtl?= =?us-ascii?Q?i0ZyTILBasSUjU2Fl0qycOQ1CjipgDvEH+8bYnzjXaxpOKT3fQ0ndJw8ULK4?= =?us-ascii?Q?qazAhGlai2tiDMasuPdQiVIcNTFBxw34aD30LG5yo7mciTbeIkXeoqLdxQAJ?= =?us-ascii?Q?4lu/ukYjsqb5JuNHEoUZJb1+UgKDCwBTNV1SmES2U57bIBxdHiNfkLFij3z/?= =?us-ascii?Q?zWwsU/6DaUL8uiwccgvRgpuVG5LQmH/cIXZjXJq5u0eE1e9SgSo7+gWVRcCY?= =?us-ascii?Q?WfVhVWv84V6MHiXHRFqZQfoUt0e+ekoxqHWT84hY8F9se6VjgDLr5DpliuAo?= =?us-ascii?Q?5ScWhtuO8D2tHSLhNB4Lvzv0ZJx1FzbNKVH8+X0aZ2it7gQtBtjxqOCCLqBP?= =?us-ascii?Q?41tkTlbhOhyOcFxuzfznaw2czmyUIQBR3+wgKCGC+0NMCtILrxyVEefMbkhM?= =?us-ascii?Q?74ybnSehxdOOqAGXUPVnxy10rG/6C3kmBabWF4s8oJW9YrWMsNaIZZoilogj?= =?us-ascii?Q?LR2ujaWJ0V28AEgGaR32ECo3Dt4/TclxomxPbmzM3BYJzi/H4MfhHUmwZEOw?= =?us-ascii?Q?xl9ffnUhJNleOMtdi+ddePFE+5JBDxBInH3aAZCqeihbzxCXycMaSusHthLl?= =?us-ascii?Q?Ka0cXy4ZLGMJbT3RSc9NvXffjK2qF4PoRAu2AfKe6gfYwcxMCW+tZH5js5/7?= =?us-ascii?Q?+n8BFVJLDL+rlmTGqCwAXto0006dOb1elFvrE9u7C1vIIY4bouy1fFyUV89T?= =?us-ascii?Q?UCXimVChbHFNu6eekXNMMGV8NcwNq2bW3clhcy6+Ci9gg2e+hNsYgYKx1MaZ?= =?us-ascii?Q?H3sYsPjhVg=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: 7434ac29-ec03-429c-f709-08da39a58245 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2022 14:40:24.3731 (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: dvrRtcVmZHIqpEV7uG6it99Kdq5Kl7ItoJ4OIOCBtAYcvyQhdOfV58/lnVdX+xrjMmMYI+TB3sc5F4v8Mh949Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3355 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 Thomas, > -----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 buf= fer > split >=20 > Hello, >=20 > 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 cur= rent > 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") >=20 > If RTE_ETH_RX_OFFLOAD_HEADER_SPLIT is not needed, let's add a comment > to start a deprecation. > " Thank you for the detailed review. First of all, I agree that header split should be deprecated. Since it is unrelated with buffer split, I was planning to send the depreca= tion notice in 22.07 sometime later and start the deprecation in 22.11. If you think it should be the first step, I will send the deprecation notic= e first. >=20 > Also the comment from Andrew about removing limitation to 2 packets is no= t > addressed. Secondly, it is said that the protocol based buffer split will divide the p= acket into two segments. Because I thought it will only be used in the split between header and payl= oad. 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 proto= s, as the split point of protocol based buffer split. And this series of proto= s, like lengths, indicate the split location. For example, a packet consists of MAC/IPV4/UDP/payload. If we define the buffer split proto with IPV4, and UDP, the packet will be split into three segments: seg0: MAC and IPV4 header, 34 bytes seg1: UDP header, 8 bytes seg2: Payload, the actual payload size What do you think of this design? >=20 > All the part about the protocols capability is missing here. 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. >=20 > 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 spli= t. > > protocol split is based on buffer split, configuring length of buffer > > split is not suitable for NICs that do split based on protocol types. >=20 > Why? Is it impossible to support length split on Intel NIC? Yes, our NIC supports split based on protocol types. And I think there are = other vendors too. The existence of tunneling results in the composition of a packet is variou= s. Given a changeable length, it is impossible to tell the driver a fixed prot= ocol type. >=20 > > Because tunneling makes the conversion from length to protocol type > > impossible. >=20 > This is not a HW issue. > I agree on the need but that a different usage than length split. I think the new usage can solve this problem, so that length split and proto 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 >=20 > Not clear what is the calculation. The previous usage of protocol based split is the split between header and = 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 42= B. >=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) { >=20 > Add a comment here, /* split at fixed length */ 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 { >=20 > Add a comment here, /* split after specified protocol header */ 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) { >=20 > (should be a space, not a tab before brace) Get it. >=20 > Why do you limit the feature to 2 segments only? 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 received = 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 defa= ult. > > + * > > + * - Protocol based buffer split: > > + * - mp, offset, proto should be configured. > > + * - The length should not be configured in protocol split. Zero d= efault. >=20 > What means "Zero default"? > You should just ignore the non relevant field. Yes, you are right, the none relevant field should be just ignored. I will update the doc in v6. >=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 buffer. > */ > > - uint32_t reserved; /**< Reserved field. */ >=20 > How do you manage ABI compatibility? > Was the reserved field initialized to 0 in previous versions? I think we reached an agreement in RFC v1. There is no document for the res= erved field in the previous release. And it is always initialized to zero in real= cases. And now splitting based on fixed length and protocol header parsing is excl= usive,=20 we can ignore the none relevant field. >=20 > > + uint32_t proto; /**< Protocol of buffer split, determines protocol > > +split point. */ >=20 > What are the values for "proto"? 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 > > > > + >=20 > It looks to be an useless change. Thanks for the catch, will fix it in next version. Thanks again for your time. 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. > > >=20 >=20 >=20 >=20