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 C559CA04FD; Tue, 23 Aug 2022 05:26:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6B52140694; Tue, 23 Aug 2022 05:26:56 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 89F7B4068E for ; Tue, 23 Aug 2022 05:26:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661225214; x=1692761214; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZHZBoMilFV8ONe3TdQM5rB1hl/Nae9zQm/4a0Y0ynYo=; b=MTPukBVsowgQSv6e9OqZChPmvIslhFhvISlSIwMElRuUm0QEgnxmYq4U CfDYoE2YPwtbKvdzvs7THhIiU7KayUrUXEHWxkoJKMoRlU0UV3Fm3KoLM ANbcilUKSISEhm15H+hZ8fYp6SuzFGVTu4xSbNiCJy8q8MpvVJaCbfkZJ vYPIlhxhZHNSJ6P3TeqnEWAWhbiRMWvq0qwWyFsODmG4dmso3pUaXJYvF GxEd57kIRqPP07ltwkEXA4pGQD0Zj824KnoYpBeva6976rwp9EY5fZJvu AWCcbQZRh4+LSklMMV92nVJiIAxrinSVcnl75lomyTgoMSFPcOZJjnX4v w==; X-IronPort-AV: E=McAfee;i="6500,9779,10447"; a="357560910" X-IronPort-AV: E=Sophos;i="5.93,256,1654585200"; d="scan'208";a="357560910" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Aug 2022 20:26:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,256,1654585200"; d="scan'208";a="669835966" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga008.fm.intel.com with ESMTP; 22 Aug 2022 20:26:48 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 22 Aug 2022 20:26:48 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 22 Aug 2022 20:26:46 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Mon, 22 Aug 2022 20:26:46 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.174) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Mon, 22 Aug 2022 20:26:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cFn3bI1o0BNxQR6V/tZgmMEfeesL/KMFYSwaNukmO/H1+Y+h3N2qfsC6NxJ+8V6B9mo5Kqe+R22p4fkRAjyo0m2coa9/yfRq3FklpIB7r0kgBIzc8KdGfdWRiNZdJFoK5qMICSYrWYRlGSPmt2skfhw90q5TX11KATyUUOEZ/B99PkuY7EhgoJ75fCxLV0guYNnwPQm7Yycv3QhM9RWZUlD59ZN/cZwOi9CHT3fdFL2gSgAxLxZO0D5yI7xrrKwlQyqbBQZV4NE5W00bdCeb2qNhAAbDLdxjvTFQdskGmiUhKFsjmfinT8WCf6CpqDEBv5pIn4ue99hixVuOFFfn7w== 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=3CVZ2fdcmVAKx4cZdmgr8TNgKQ53+5bmWoP5VRPLy8I=; b=P13fyxZHqrrYQAv0/cgXL1UboFZfpQTMTWIlVOwskmXxDev8e3e0jqIOEGFvNZv2eoujbgzwVZwFqT1ZWZq8Sdjdnr+cx5bJu87EUsdfePrWd0m8Cy0i9lB3tL5nVZIIJzpdekDvnr2Rv1woTy8Xp2MYTcRdDlOZLPaL/CLmRlwMtAtJmMAEaRwQSlHI5KPkyBivZxbekf4Td7XcPfg3zsB+ZPoJggzW2r68fq54PPJH+2nNSYdAV3m+Omy7eoPfW6MoAOerEYBW3mtu19qQ5M7mu9xm2JZ0wNvzOFE6NrLpiVHeV1PN71qreQTxq42r/ZBVOGnZ6PkZR6KAta9Xaw== 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 DM6PR11MB3321.namprd11.prod.outlook.com (2603:10b6:5:8::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.21; Tue, 23 Aug 2022 03:26:39 +0000 Received: from BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::31a0:2c90:65e9:7647]) by BN9PR11MB5513.namprd11.prod.outlook.com ([fe80::31a0:2c90:65e9:7647%8]) with mapi id 15.20.5546.022; Tue, 23 Aug 2022 03:26:38 +0000 From: "Ding, Xuan" To: Hanumanth Pothula , Thomas Monjalon , Ferruh Yigit , "Andrew Rybchenko" CC: "dev@dpdk.org" , "Wu, WenxuanX" , "Li, Xiaoyun" , "stephen@networkplumber.org" , "Wang, YuanX" , "mdr@ashroe.eu" , "Zhang, Yuying" , "Zhang, Qi Z" , "viacheslavo@nvidia.com" , "jerinj@marvell.com" , "ndabilpuram@marvell.com" Subject: RE: [PATCH v2 1/3] ethdev: introduce pool sort capability Thread-Topic: [PATCH v2 1/3] ethdev: introduce pool sort capability Thread-Index: AQHYrnDTCbGSIk8QA0KH9KLFwFNYSa273haw Date: Tue, 23 Aug 2022 03:26:38 +0000 Message-ID: References: <20220812104648.1019978-1-hpothula@marvell.com> <20220812172451.1208933-1-hpothula@marvell.com> In-Reply-To: <20220812172451.1208933-1-hpothula@marvell.com> 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: ddf5d082-3f4f-47fd-9f81-08da84b74a6a x-ms-traffictypediagnostic: DM6PR11MB3321:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8/X7o6f7CFfOX/ATKZpOD7sOf5NjkOabsku8AHWrIniNs0lu655VA+jhDY3IAxZ66VuR2XRgPkzQLuq/EdxUgBMFS7pspTEgDQC9IVdlyRtDmI1ijNh80JgnAecxj74hMpKaWblFifEcAcrNvMunJjdq9tGpA2okg7Z9pJ+dJId3bGiX7mGI3oilJiEohtIAzk6PWZnCZOsC7cJc5WVK8DxE+eYrUMDjXRok+Hw0Sf1szvMhw5VajnZDI9AuMjsYobCjYWdwHgQu/AJ7znjQtePdtD/pVh/8Qrw/V8bPDjmL7lfFT3CfINrnSgBRi0C3KaZMbFoK1FUHhLyqnbcVdHyt7lTppx9uToZWysmDgElT1rbl2EQSp0mtXkm2/d/0sUm46GpStmrF+/cIjyajpr4gc6jgx70p8vFtfjhsFOW73vvC/IS2dkulml4c36Y7+RF0leV5CMalphPHfVxyDOP4unh87OJWOH9yO722/zVQp49gMfRQ9DX/xDgu1vtmqE29ozv3dGkfq9nGkCSFYziwj3QGcuUOSRAnQjQZY2TmT8gytu4PfN8b5XJtI1oMl/qUFvPq8Z0PdpC+4Fr/nuW9T5FCRyZP2CfAtHtD6qMGkHRso0ffV0vAHviIQJGVrm+aLdmJVaOUVMMPgoN96lkd9M0p4oV3NRbppS6qi8u0FTNYFAML5z4KEubVD92PzSO2QDcxiav22ZEjAOxw1MYKxhNve7nJhblEDU7VZKWI7IiMwjQM8FmR2Uizj31BTF9VaehE3ZBIHVUWtOStxg== 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:(13230016)(376002)(396003)(366004)(39860400002)(136003)(346002)(66946007)(66476007)(8676002)(2906002)(76116006)(83380400001)(66556008)(64756008)(4326008)(66446008)(38070700005)(82960400001)(52536014)(38100700002)(8936002)(7416002)(30864003)(122000001)(5660300002)(9686003)(316002)(26005)(33656002)(71200400001)(55016003)(54906003)(41300700001)(110136005)(478600001)(86362001)(53546011)(186003)(6506007)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?a5OEsgwUGU01z/1wIBogzebm7J5Xim5AVk1ZEftMisuKjerSs905AP7OE7gb?= =?us-ascii?Q?IPFwP5iR9t+7BlDLDNWpvY1S2ZaWl0TcZLuWM24IfYnNSFoSfhjKKgEPECDG?= =?us-ascii?Q?uyb5V4fLfEAll9PLjh19rgAADQR8R2wG6D9LUA5FhvB1BMk7cQT6/xZn0ZHn?= =?us-ascii?Q?jFV8BQ2gK5dolGh8m6HJKcVfP7ypaszrUDxfw1bOwleBSV8twmOTG0+fe1R8?= =?us-ascii?Q?7WU5q6/fpJMIp598YhWoz6s/ibkVAj/aVnyabj/N2syrBOJRBOpvOm7o2FsA?= =?us-ascii?Q?Gyug9u0FvysE/jdOC3oHdG4e92hzmDMjAeHfzdpHPaBeGRFByGZFLWZygg5n?= =?us-ascii?Q?w7y04/ajSfRAmnhTIyrHZo2b45iYkPxbKdui8sxDM2cDYednEIk9SzAetKlg?= =?us-ascii?Q?GbzVGIB2B3JhNLkid77mdfTQAtoObyu6FLweIo/IBlCR6sLdsoG9ek57f6ui?= =?us-ascii?Q?0KgFiEjXUE9VJJj/hvGd8nrOaJHS7vpSBu1r9mvBOtn6dZUghjC1RIu1m5og?= =?us-ascii?Q?FIqx9pymKAL/LmaegjxiBJ+C9tzRgeYFFiiXgf4+NdHMgb3+Clb+nj/yy5bv?= =?us-ascii?Q?nVLmwChiCwJrOy8iTm/VujRcVzUpWemptFWHF2zcsLe+UEY4DkDEKx2XmvCJ?= =?us-ascii?Q?7NZogVZCTvtuoiyy/6kJu24zoqxJwEseatrO4dt+l1BklpVUxq80jjGQmt7P?= =?us-ascii?Q?aPcmycLN62jm1ilRUp1tTydPV2q1mZb5zq9hn95z4Xkuv+2+gtIvOh1marfx?= =?us-ascii?Q?ieeuUdzzpTiDdqmdNsSm/0b2ri56VurE2C2FRMfKIrhZPulRQ/dIYh7D916r?= =?us-ascii?Q?BNNbmAACmGjyA2+SuvRwL+819piQDK5ny+YvBBCh+3Gvvw9mUWAGy+AAtlE1?= =?us-ascii?Q?2v+SyK+/5WcJCpajGQvgDSN8OHfhGxVmhN8BEu7TS4E7zfC2pEmESG2at8X/?= =?us-ascii?Q?b+hBuvMNDysNLJDpAGJoq0cFC1LNMaIsNMDnYvA545DQy/IDtelc+Id7zzsM?= =?us-ascii?Q?bxhzEgoomferDznQTOKWqn+2HboINPDLELw9+1+KerFTdKhLEkiA5jiIb7Zg?= =?us-ascii?Q?InEs2AkhAOONmKMr1le5AfJCQBSga9Redt/Kq67VP5n8FCaI4EjaxZ7qWhpG?= =?us-ascii?Q?z6/yo5y1O0SdVPy0rGYSz6w0wS8DwOq3s2y6K7xpmVzdIctYKFCPqLbcYTCv?= =?us-ascii?Q?VbXdG4aoTVK66MYmqdQ+xZwSIChJ1Vy+4vb5lxgTSCBiwxQY4oEeWJc0hV0Y?= =?us-ascii?Q?sT07Y/HyjvM3/0g9+tapKnWAClC2hp7ehAb+8s6xtgAIlDPVASGO601s5l92?= =?us-ascii?Q?p3nkKAvpXcvgcOqfUKTqFOP1rK/9O6xG4/vQOpp1aq1H/4bZdGltGCaJAKQS?= =?us-ascii?Q?vigqNM0+jg38hseVlU9tOZkqd54ZSAKFfrsZrToJNobxgo3ZuoFyEqFrMfZU?= =?us-ascii?Q?VMt6Q6/XJwpvpXOpTrQXh4YRTD4NRD8GklUX4CiViNx+1fSkV55hauh+nKEZ?= =?us-ascii?Q?mZfDN+RImyRihHfwFo7MpymRJZBtjuru53eJwS0U5OTL4oy5z+CWkWU4UEkO?= =?us-ascii?Q?gHCYsKv4HMYL4Fi7/FmYMtv4bNjv7/kWGiB9QSzW?= 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: ddf5d082-3f4f-47fd-9f81-08da84b74a6a X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2022 03:26:38.8260 (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: BVxtZjH28kTFTz7iIVi6XJyHL5d5mzTWLpGsUrjHcWVj7EjPKLA3mrnhWaArYPb6C6pL93yFXEDixv/enXUVdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3321 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 Hanumanth, > -----Original Message----- > From: Hanumanth Pothula > Sent: Saturday, August 13, 2022 1:25 AM > To: Thomas Monjalon ; Ferruh Yigit > ; Andrew Rybchenko > > Cc: dev@dpdk.org; Ding, Xuan ; Wu, WenxuanX > ; Li, Xiaoyun ; > stephen@networkplumber.org; Wang, YuanX ; > mdr@ashroe.eu; Zhang, Yuying ; Zhang, Qi Z > ; viacheslavo@nvidia.com; jerinj@marvell.com; > ndabilpuram@marvell.com; Hanumanth Pothula > Subject: [PATCH v2 1/3] ethdev: introduce pool sort capability >=20 > Presently, the 'Buffer Split' feature supports sending multiple segments = of > the received packet to PMD, which programs the HW to receive the packet i= n > segments from different pools. >=20 > This patch extends the feature to support the pool sort capability. > Some of the HW has support for choosing memory pools based on the > packet's size. The pool sort capability allows PMD to choose a memory poo= l > based on the packet's length. >=20 > This is often useful for saving the memory where the application can crea= te a > different pool to steer the specific size of the packet, thus enabling ef= fective > use of memory. >=20 > For example, let's say HW has a capability of three pools, > - pool-1 size is 2K > - pool-2 size is > 2K and < 4K > - pool-3 size is > 4K > Here, > pool-1 can accommodate packets with sizes < 2K > pool-2 can accommodate packets with sizes > 2K and < 4K > pool-3 can accommodate packets with sizes > 4K >=20 > With pool sort capability enabled in SW, an application may create three > pools of different sizes and send them to PMD. Allowing PMD to program > HW based on packet lengths. So that packets with less than 2K are receive= d > on pool-1, packets with lengths between 2K and 4K are received on pool-2 > and finally packets greater than 4K are received on pool-3. >=20 > The following two capabilities are added to the rte_eth_rxseg_capa struct= ure, > 1. pool_sort --> tells pool sort capability is supported by HW. > 2. max_npool --> max number of pools supported by HW. >=20 > Defined new structure rte_eth_rxseg_sort, to be used only when pool sort > capability is present. If required this may be extended further to suppor= t > more configurations. >=20 > Signed-off-by: Hanumanth Pothula >=20 > v2: > - Along with spec changes, uploading testpmd and driver changes. Thanks for CCing. It's an interesting feature. But I have one question here: Buffer split is for split receiving packets into multiple segments, while p= ool sort supports PMD to put the receiving packets into different pools according to packet s= ize. Every packet is still intact. So, at this level, pool sort does not belong to buffer split. And you already use a different function to check pool sort rather than che= ck buffer split. Should a new RX offload be introduced? like "RTE_ETH_RX_OFFLOAD_POOL_SORT". > --- > lib/ethdev/rte_ethdev.c | 87 +++++++++++++++++++++++++++++++++++------ > lib/ethdev/rte_ethdev.h | 45 +++++++++++++++++++-- > 2 files changed, 118 insertions(+), 14 deletions(-) >=20 > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index > 1979dc0850..7fd5443eb8 100644 > --- a/lib/ethdev/rte_ethdev.c > +++ b/lib/ethdev/rte_ethdev.c > @@ -1635,7 +1635,55 @@ rte_eth_dev_is_removed(uint16_t port_id) } >=20 > static int > -rte_eth_rx_queue_check_split(const struct rte_eth_rxseg_split *rx_seg, > +rte_eth_rx_queue_check_sort(const struct rte_eth_rxseg *rx_seg, > + uint16_t n_seg, uint32_t *mbp_buf_size, > + const struct rte_eth_dev_info *dev_info) { > + const struct rte_eth_rxseg_capa *seg_capa =3D &dev_info- > >rx_seg_capa; > + uint16_t seg_idx; > + > + if (!seg_capa->multi_pools || n_seg > seg_capa->max_npool) { > + RTE_ETHDEV_LOG(ERR, > + "Invalid capabilities, multi_pools:%d differnt > length segments %u exceed supported %u\n", > + seg_capa->multi_pools, n_seg, seg_capa- > >max_nseg); > + return -EINVAL; > + } > + > + for (seg_idx =3D 0; seg_idx < n_seg; seg_idx++) { > + struct rte_mempool *mpl =3D rx_seg[seg_idx].sort.mp; > + uint32_t length =3D rx_seg[seg_idx].sort.length; > + > + if (mpl =3D=3D NULL) { > + RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); > + return -EINVAL; > + } > + > + if (mpl->private_data_size < > + sizeof(struct rte_pktmbuf_pool_private)) { > + RTE_ETHDEV_LOG(ERR, > + "%s private_data_size %u < %u\n", > + mpl->name, mpl->private_data_size, > + (unsigned int)sizeof > + (struct rte_pktmbuf_pool_private)); > + return -ENOSPC; > + } > + > + *mbp_buf_size =3D rte_pktmbuf_data_room_size(mpl); > + length =3D length !=3D 0 ? length : (*mbp_buf_size - > RTE_PKTMBUF_HEADROOM); > + if (*mbp_buf_size < length + RTE_PKTMBUF_HEADROOM) { > + RTE_ETHDEV_LOG(ERR, > + "%s mbuf_data_room_size %u < %u))\n", > + mpl->name, *mbp_buf_size, > + length); > + return -EINVAL; > + } > + } > + > + return 0; > +} > + > +static int > +rte_eth_rx_queue_check_split(const struct rte_eth_rxseg *rx_seg, > uint16_t n_seg, uint32_t *mbp_buf_size, > const struct rte_eth_dev_info *dev_info) { @@ - > 1654,12 +1702,12 @@ rte_eth_rx_queue_check_split(const struct > rte_eth_rxseg_split *rx_seg, > * Check the sizes and offsets against buffer sizes > * for each segment specified in extended configuration. > */ > - mp_first =3D rx_seg[0].mp; > + mp_first =3D rx_seg[0].split.mp; > offset_mask =3D RTE_BIT32(seg_capa->offset_align_log2) - 1; > for (seg_idx =3D 0; seg_idx < n_seg; seg_idx++) { > - 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; > + struct rte_mempool *mpl =3D rx_seg[seg_idx].split.mp; > + uint32_t length =3D rx_seg[seg_idx].split.length; > + uint32_t offset =3D rx_seg[seg_idx].split.offset; >=20 > if (mpl =3D=3D NULL) { > RTE_ETHDEV_LOG(ERR, "null mempool pointer\n"); > @@ -1693,7 +1741,11 @@ 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; > + /* On segment length =3D=3D 0, update segment's length with > + * the pool's length - headeroom space, to make sure enough > + * space is accomidate for header. > + **/ > + length =3D length !=3D 0 ? length : (*mbp_buf_size - > +RTE_PKTMBUF_HEADROOM); > 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", @@ -1764,7 +1816,6 @@ > rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id, > return -EINVAL; > } > } else { > - const struct rte_eth_rxseg_split *rx_seg; > uint16_t n_seg; >=20 > /* Extended multi-segment configuration check. */ @@ - > 1774,13 +1825,27 @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t > rx_queue_id, > return -EINVAL; > } >=20 > - rx_seg =3D (const struct rte_eth_rxseg_split *)rx_conf->rx_seg; > n_seg =3D rx_conf->rx_nseg; >=20 > if (rx_conf->offloads & RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT) > { > - ret =3D rte_eth_rx_queue_check_split(rx_seg, n_seg, > - &mbp_buf_size, > - &dev_info); > + ret =3D -1; /* To make sure at least one of below > conditions becomes > +true */ > + > + /* Check both NIX and application supports buffer- > split capability */ > + if (dev_info.rx_seg_capa.mode_split && > + rx_conf->mode_flag =3D=3D > RTE_ETH_RXSEG_MODE_SPLIT) { > + ret =3D rte_eth_rx_queue_check_split(rx_conf- > >rx_seg, n_seg, > + > &mbp_buf_size, > + &dev_info); > + } > + > + /* Check both NIX and application supports pool-sort > capability */ > + if (dev_info.rx_seg_capa.mode_sort && > + rx_conf->mode_flag =3D=3D > RTE_ETH_RXSEG_MODE_SORT) { > + ret =3D rte_eth_rx_queue_check_sort(rx_conf- > >rx_seg, n_seg, > + > &mbp_buf_size, > + &dev_info); > + } > + > if (ret !=3D 0) > return ret; > } else { > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > de9e970d4d..9f6787d7ad 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1204,16 +1204,46 @@ struct rte_eth_rxseg_split { > uint32_t reserved; /**< Reserved field. */ }; >=20 > +/** > + * The pool sort capability allows PMD to choose a memory pool based on > +the > + * packet's length. So, basically, PMD programs HW for receiving > +packets from > + * different pools, based on the packet's length. > + * > + * This is often useful for saving the memory where the application can > +create > + * a different pool to steer the specific size of the packet, thus > +enabling > + * effective use of memory. > + */ > +struct rte_eth_rxseg_sort { > + struct rte_mempool *mp; /**< Memory pool to allocate packets > from. */ > + uint16_t length; /**< Packet data length. */ > + uint32_t reserved; /**< Reserved field. */ }; > + > +enum rte_eth_rxseg_mode { > + /** > + * Buffer split mode: PMD split the received packets into multiple > segments. > + * @see struct rte_eth_rxseg_split > + */ > + RTE_ETH_RXSEG_MODE_SPLIT =3D RTE_BIT64(0), > + /** > + * Pool sort mode: PMD to chooses a memory pool based on the > packet's length. > + * @see struct rte_eth_rxseg_sort > + */ > + RTE_ETH_RXSEG_MODE_SORT =3D RTE_BIT64(1), }; > + > /** > * @warning > * @b EXPERIMENTAL: this structure may change without prior notice. > * > * A common structure used to describe Rx packet segment properties. > */ > -union rte_eth_rxseg { > +struct rte_eth_rxseg { > /* The settings for buffer split offload. */ > struct rte_eth_rxseg_split split; > - /* The other features settings should be added here. */ > + > + /*The settings for packet sort offload. */ > + struct rte_eth_rxseg_sort sort; > }; >=20 > /** > @@ -1239,6 +1269,11 @@ struct rte_eth_rxconf { > * fields on rte_eth_dev_info structure are allowed to be set. > */ > uint64_t offloads; > + /** > + * PMD may support more than one rxseg mode. This allows > application > + * to chose which mode to enable. > + */ > + enum rte_eth_rxseg_mode mode_flag; > /** > * Points to the array of segment descriptions for an entire packet. > * Array elements are properties for consecutive Rx segments. > @@ -1246,7 +1281,7 @@ struct rte_eth_rxconf { > * The supported capabilities of receiving segmentation is reported > * in rte_eth_dev_info.rx_seg_capa field. > */ > - union rte_eth_rxseg *rx_seg; > + struct rte_eth_rxseg *rx_seg; >=20 > uint64_t reserved_64s[2]; /**< Reserved for future fields */ > void *reserved_ptrs[2]; /**< Reserved for future fields */ > @@ -1827,10 +1862,14 @@ struct rte_eth_switch_info { > */ > struct rte_eth_rxseg_capa { > __extension__ > + uint32_t mode_split : 1; /**< Supports buffer split capability @see > struct rte_eth_rxseg_split */ > + uint32_t mode_sort : 1; /**< Supports pool sort capability @see > struct The same doubt here. As I know, the 'rte_eth_rxseg_capa' structure is used = for buffer split. Thanks, Xuan > +rte_eth_rxseg_sort */ > uint32_t multi_pools:1; /**< Supports receiving to multiple pools.*/ > uint32_t offset_allowed:1; /**< Supports buffer offsets. */ > uint32_t offset_align_log2:4; /**< Required offset alignment. */ > uint16_t max_nseg; /**< Maximum amount of segments to split. */ > + /* < Maximum amount of pools that PMD can sort based on > packet/segment lengths */ > + uint16_t max_npool; > uint16_t reserved; /**< Reserved field. */ }; >=20 > -- > 2.25.1