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 67184A0548; Sun, 10 Oct 2021 08:30:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E598D40042; Sun, 10 Oct 2021 08:30:54 +0200 (CEST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2040.outbound.protection.outlook.com [40.107.102.40]) by mails.dpdk.org (Postfix) with ESMTP id C2C9C40040 for ; Sun, 10 Oct 2021 08:30:52 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WfUOH1/5pwZZ61TbI6aYR1e5Sc4MLNVeMMVtPUN/mBpxcW4gPzwTuyMreu8wGsVplmZVOdocM7vE2Pm47h4/FDJ4N3as0Wm0kZJV1V84AWFyc4lD6thIeGbzgfxCaDH6ySnrzaeFgI3h+quOSXaR3aVdYwojgGZ0cs86+mxmEXWPtu8IDiJEdqqa5YoEIyTdqJW11l0uM17O6ZsEvTEA6+dn/2+mihD9UbDg06Hm8E0Brw1MXYHVtLenXkO+zQ7RTr5VdG4aRHP1xkjYyrm0BK86Rz06c6Es99SXuX8VZ6uuexsSiA9Ijkay4iYP/A7FxDf549uHsD8fKTaSvFHm+A== 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=Q/kMinpAAuCV+dZN2TPNhFa0faF7+5fgZani+pgKrXQ=; b=WPnFZ2ynYa0TFJyBAGTqENHwaXHtzBBbj2qQBs4EXLe40A/KkYZ9+S2002SPX7BF1vCa7EtbrLhrO6DgNxSWH/VdQheyIZY6013ZtMArgLDLALhwoEQ/VfD9rEeMwAEn927xnIt3KnEArAdD6EVwfDiNTpM7BkIChFG1IMPmhn5Tv1LWyuIhYp52wecg/bn0feKSV1kZ4C6Sm3BilHdbkKYzau4P3dOnBptYPR6QqnpicJAxXewNzzROn9tZjUhHEhk+pY/Kv47PMXevpPQ7Udj/4bYnV/J4Onvq8vozvKAvlaumK/GDW887uigJhaEOYDjkcdWT1j8v/rjB+mP/YQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q/kMinpAAuCV+dZN2TPNhFa0faF7+5fgZani+pgKrXQ=; b=V+IQz1bim+0IAHnsEZcifs8coTquRw8Y6jkuLbsTmkZQhaXOdpcpGAAE5GPh1UGDJVseenyIe+FecgzJXg+pZYVg01AcuFE9D8T502hFRjghHWUTWEcWJbnaeWBzhLlpwXnja0OWZ1pV1A9Gf2MDHrP0lhCGzMcrzob2uOCgCQFVTDZvXaiwtGif1Cgnc8quU0DoqdyH2WKk7mvG6bhuSUMyas29ay01bg6a4Lhq10mDczuejWclIcA95VB02viBoCQVXvIroi/rz6daIa4DrSAt3w8j3Ka6cxq3+PFepa9KbgDubb8G+O5AuuTwT+pUFLwP7A2gaRHwnU8HcNwXbw== Received: from DM4PR12MB5389.namprd12.prod.outlook.com (2603:10b6:5:39a::7) by DM4PR12MB5038.namprd12.prod.outlook.com (2603:10b6:5:389::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Sun, 10 Oct 2021 06:30:50 +0000 Received: from DM4PR12MB5389.namprd12.prod.outlook.com ([fe80::45be:2914:19ef:f4bb]) by DM4PR12MB5389.namprd12.prod.outlook.com ([fe80::45be:2914:19ef:f4bb%3]) with mapi id 15.20.4587.025; Sun, 10 Oct 2021 06:30:50 +0000 From: Matan Azrad To: Ferruh Yigit , Jerin Jacob , Xiaoyun Li , Chas Williams , "Min Hu (Connor)" , Hemant Agrawal , Sachin Saxena , Qi Zhang , Xiao Wang , Slava Ovsiienko , Harman Kalra , Maciej Czekaj , Ray Kinsella , Bernard Iremonger , Konstantin Ananyev , Kiran Kumar K , Nithin Dabilpuram , David Hunt , John McNamara , Bruce Richardson , Igor Russkikh , Steven Webster , Matt Peters , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , Somnath Kotur , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Haiyue Wang , Marcin Wojtas , Michal Krawczyk , Shai Brandes , Evgeny Schemeilin , Igor Chauskin , Gagandeep Singh , John Daley , Hyong Youb Kim , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , Yisen Zhuang , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Andrew Boyer , Rosen Xu , Shijith Thotton , Srisivasubramanian Srinivasan , Zyta Szpak , Liron Himi , Heinrich Kuhn , Devendra Singh Rawat , Andrew Rybchenko , Keith Wiles , Jiawen Wu , Jian Wang , Maxime Coquelin , Chenbo Xia , Nicolas Chautru , Harry van Haaren , Cristian Dumitrescu , Radu Nicolau , Akhil Goyal , Tomasz Kantecki , Declan Doherty , Pavan Nikhilesh , Kirill Rybalchenko , Jasvinder Singh , NBU-Contact-Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [PATCH v4 1/6] ethdev: fix max Rx packet length Thread-Index: AQHXug1PrvDNXYiPrkCnnR9TAaVAm6vLxcog Date: Sun, 10 Oct 2021 06:30:49 +0000 Message-ID: References: <20211001143624.3744505-1-ferruh.yigit@intel.com> <20211005171653.3700067-1-ferruh.yigit@intel.com> In-Reply-To: <20211005171653.3700067-1-ferruh.yigit@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f07129a8-e5be-4c0b-5899-08d98bb7808d x-ms-traffictypediagnostic: DM4PR12MB5038: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /4r5lk2pFwZRReaR3L73/1pAfjkvULmw70JAn48L4RKooyo8buxYjzycfVDBPimLOTXDeZ2l+AuVMRIBJdFtKb08lm4oX68JxUXQCFxJpliPfBgifNEH2B+0x1YVGlXCKCJt/lYirWou+dygTrxERPTJpukOEy8lFSB23OUmZgIhYPi2le+qfkwekal+9rCZ6g8g+zXTu7T50PIpnI3fq5T2OuIaLTVvEEtS2KcPIcK22eGlTvOhaVXH/pmlYNhuCsWQlMC41wFSj/mDIeQIRMkWvogxqhVR+KQLYfJ054Oe0HUy8z0Ost5Foq4GSJJbVKEWsqct/jaEDADg9Uhb/42GfHRBJvT8wjZm7lenN6EbMN/BiFcblam3ET+OeW3ZCZCNAkPSe10UseKyi2C1z35kiyeq3XRb6l+Za6WtxLMG8n7P+eOwMJRfTPTCR/4tILYmiPHhNyLbgU7pq9OrMDwCK4VjOC7KawaqmGAJnyC3mClhQomcr1e5lEB12zHGMNqvDLqAG/yC3tsnmWvGID0zKPtODz8QYcjbvpwCrNHLuhYivZvIzfUuWTxxCRbxJZwdom20zicJk+UYPRjVBqhq6tR6szQ7QgORwB1TgzAQu2VZlde+ju38l1xpB2v9LnS1HlAcYalymLN2ZofVSkLbBjvM7vOE0euDAGt4C5oNlTxPDDd0MgWaV+yzNsvICcVZO4Fc1kpj8mxMdtvnkafU2Qnb+M171qX/MYW1L20= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR12MB5389.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(26005)(76116006)(2906002)(7696005)(5660300002)(8676002)(6506007)(508600001)(38100700002)(921005)(122000001)(7416002)(83380400001)(4326008)(66556008)(110136005)(55016002)(316002)(66476007)(38070700005)(7366002)(1191002)(7406005)(66946007)(66446008)(52536014)(64756008)(186003)(71200400001)(33656002)(8936002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?I2dDwS5g0yoyY7sUzeaIYapWTZJSX/QQSa90deViOy0k7tqbeiqPKuyXMwuj?= =?us-ascii?Q?vqeNwhe/lG7pUR907FIYxfaHnL9PSi8G0zusu8++WPOi2WhoGddgbznDFK8E?= =?us-ascii?Q?Y5VlQz7BuzjC59Js8ihoNo0DNefgpUYt/371H+OlgL2n60xxFCOMFa0jVs5m?= =?us-ascii?Q?08/mgMswyu4/ItsijH6FHdXaJgsdj6F+G1zFfXaJATAlhViGkfCkdIR7TCA5?= =?us-ascii?Q?wyrdtTGUUhhR8wL4iWRRnoEX3mHyj9GKrmmvmX/7+1X6aZO/0INXpT0G/G3U?= =?us-ascii?Q?nPYXt96+B9+GQi2M417nLJYVYIA9Qq2z5P1JYJwAmisYoNayI6ygAyHsEwRv?= =?us-ascii?Q?90iNd0tVXUiPIpkYcKMfGRHj+t9Cv5TnCjIGr48vZhoFlH0ZMOC+0i7nMN3U?= =?us-ascii?Q?2AsAFqf2vUuLWuVGPcQ+df9573PfJ8ZeoQYfvhB80lDyCxpjEXyUO0dHZnz9?= =?us-ascii?Q?CpoXbzsd3tE1fi9gPqD+i16gZjr5C+kSd10AfR1fNYqsBaaljD8Q8L7YU912?= =?us-ascii?Q?35jdjoaB7DPl1ez3TvWII5zXPmeqBuMiFcF6VhZMkz6Zm3UWkVVLVXCBchZc?= =?us-ascii?Q?gJOkUXh7Ap+f5orJncIJhlh5q2r5MatnDw6aHWrIFnCPZxkqQsPoQfxMrLCw?= =?us-ascii?Q?8ua2R52dsonbV6ySzRljRZezuUfECn077ntw/pdKOW5PuLwDcp0TpIN3c9o4?= =?us-ascii?Q?kTI7L1xiYeB6HVLzuaxIObGoF4wz5GHSCJapsJDOCBfmQyYxD86FV6FZRfU2?= =?us-ascii?Q?sqXhnVg4CA631CPVnVuyEzXO7akFcwkXxKkMKovZMPoklr/aYARXOgyiiaxo?= =?us-ascii?Q?157lIuXqWlHjuC8hPxjNYNOq237R5pL/0oVHvN2nqaBGtN7RC15NQSK7u8Uw?= =?us-ascii?Q?dYEm2xdeFmVZCmbGLrurZoB/Jp0OtE0f+EWRo1i+3SprltwIyYh/djycExQX?= =?us-ascii?Q?FXQG+L8ZWl1wJY5T2VysiDkEup7o1miTYYq2YmAduDV0FjmPb9lz1cd9TG1Z?= =?us-ascii?Q?JULgjBqjJ0ExvsOvzEes7Pp0dX18kbgybvI4zv70jwhnyfjPeZAsjUpFZwQW?= =?us-ascii?Q?0Zjx6pEZLGuXDSyjlK7FCH5hzhSWhG7SO6FCnK4lBodiAfndjcJL6S9BDYzK?= =?us-ascii?Q?NypXzB2ekH/dlWQKqvG1h8DZO9rc0IPSGtBqMY1GVT5A5KMceXpCGZxMCVRW?= =?us-ascii?Q?M2iXRHRkt6K4434aX1qy15cHrG5aed2uDJxV3w83RDgN+nw55OVvoH1AK41f?= =?us-ascii?Q?8mWSYc1f4i5RazM6svLZg5IIVg07HpfSUAvpvslglmdHqF4nfSbFpvtlZoFw?= =?us-ascii?Q?ATXQ+ZNCkI7x2hgJEu0xRduQ?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5389.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f07129a8-e5be-4c0b-5899-08d98bb7808d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2021 06:30:49.9508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G9lbuFRa672aS+Qf7g1kDEJZd2u76rNmROqYodGIkF2ErsiNKd8hYVU6c5WNcC1qm14zRKnK3T1XIuIeUPsr5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5038 Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: fix max Rx packet length 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 Sender: "dev" Hi Ferruh From: Ferruh Yigit > There is a confusion on setting max Rx packet length, this patch aims to > clarify it. >=20 > 'rte_eth_dev_configure()' API accepts max Rx packet size via > 'uint32_t max_rx_pkt_len' field of the config struct 'struct > rte_eth_conf'. >=20 > Also 'rte_eth_dev_set_mtu()' API can be used to set the MTU, and result > stored into '(struct rte_eth_dev)->data->mtu'. >=20 > These two APIs are related but they work in a disconnected way, they > store the set values in different variables which makes hard to figure > out which one to use, also having two different method for a related > functionality is confusing for the users. >=20 > Other issues causing confusion is: > * maximum transmission unit (MTU) is payload of the Ethernet frame. And > 'max_rx_pkt_len' is the size of the Ethernet frame. Difference is > Ethernet frame overhead, and this overhead may be different from > device to device based on what device supports, like VLAN and QinQ. > * 'max_rx_pkt_len' is only valid when application requested jumbo frame, > which adds additional confusion and some APIs and PMDs already > discards this documented behavior. > * For the jumbo frame enabled case, 'max_rx_pkt_len' is an mandatory > field, this adds configuration complexity for application. >=20 > As solution, both APIs gets MTU as parameter, and both saves the result > in same variable '(struct rte_eth_dev)->data->mtu'. For this > 'max_rx_pkt_len' updated as 'mtu', and it is always valid independent > from jumbo frame. >=20 > For 'rte_eth_dev_configure()', 'dev->data->dev_conf.rxmode.mtu' is user > request and it should be used only within configure function and result > should be stored to '(struct rte_eth_dev)->data->mtu'. After that point > both application and PMD uses MTU from this variable. >=20 > When application doesn't provide an MTU during 'rte_eth_dev_configure()' > default 'RTE_ETHER_MTU' value is used. >=20 > Additional clarification done on scattered Rx configuration, in > relation to MTU and Rx buffer size. > MTU is used to configure the device for physical Rx/Tx size limitation, > Rx buffer is where to store Rx packets, many PMDs use mbuf data buffer > size as Rx buffer size. > PMDs compare MTU against Rx buffer size to decide enabling scattered Rx > or not. If scattered Rx is not supported by device, MTU bigger than Rx > buffer size should fail. Should it be compared also against max_lro_pkt_size for the SCATTER enablin= g by the PMD? What do you think about enabling SCATTER by the API instead of making the c= omparison in each PMD? > Signed-off-by: Ferruh Yigit Please see more below regarding SCATTER. =20 > diff --git a/drivers/net/mlx4/mlx4_rxq.c b/drivers/net/mlx4/mlx4_rxq.c > index 978cbb8201ea..4a5cfd22aa71 100644 > --- a/drivers/net/mlx4/mlx4_rxq.c > +++ b/drivers/net/mlx4/mlx4_rxq.c > @@ -753,6 +753,7 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, > uint16_t idx, uint16_t desc, > int ret; > uint32_t crc_present; > uint64_t offloads; > + uint32_t max_rx_pktlen; >=20 > offloads =3D conf->offloads | dev->data->dev_conf.rxmode.offloads= ; >=20 > @@ -828,13 +829,11 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, > uint16_t idx, uint16_t desc, > }; > /* Enable scattered packets support for this queue if necessary. = */ > MLX4_ASSERT(mb_len >=3D RTE_PKTMBUF_HEADROOM); > - if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=3D > - (mb_len - RTE_PKTMBUF_HEADROOM)) { > + max_rx_pktlen =3D dev->data->mtu + RTE_ETHER_HDR_LEN + > RTE_ETHER_CRC_LEN; > + if (max_rx_pktlen <=3D (mb_len - RTE_PKTMBUF_HEADROOM)) { > ; > } else if (offloads & DEV_RX_OFFLOAD_SCATTER) { > - uint32_t size =3D > - RTE_PKTMBUF_HEADROOM + > - dev->data->dev_conf.rxmode.max_rx_pkt_len; > + uint32_t size =3D RTE_PKTMBUF_HEADROOM + max_rx_pktlen; > uint32_t sges_n; >=20 > /* > @@ -846,21 +845,19 @@ mlx4_rx_queue_setup(struct rte_eth_dev *dev, > uint16_t idx, uint16_t desc, > /* Make sure sges_n did not overflow. */ > size =3D mb_len * (1 << rxq->sges_n); > size -=3D RTE_PKTMBUF_HEADROOM; > - if (size < dev->data->dev_conf.rxmode.max_rx_pkt_len) { > + if (size < max_rx_pktlen) { > rte_errno =3D EOVERFLOW; > ERROR("%p: too many SGEs (%u) needed to handle" > " requested maximum packet size %u", > (void *)dev, > - 1 << sges_n, > - dev->data->dev_conf.rxmode.max_rx_pkt_len); > + 1 << sges_n, max_rx_pktlen); > goto error; > } > } else { > WARN("%p: the requested maximum Rx packet size (%u) is" > " larger than a single mbuf (%u) and scattered" > " mode has not been requested", > - (void *)dev, > - dev->data->dev_conf.rxmode.max_rx_pkt_len, > + (void *)dev, max_rx_pktlen, > mb_len - RTE_PKTMBUF_HEADROOM); > } If, by definition, SCATTER should be enabled implicitly by the PMD accordin= g to the comparison you wrote above, maybe this check for SCATTER offload i= s not needed. Also, it can be documented on SCATTER offload precisely the parameters that= are used for the comparison and that it is for capability only and no need= to configure it. Also, for the case of multi RX mempools configuration, it can be implicitly= understood by the PMDs to enable SCATTER and no need to check that in PMD/= API. What do you think? > DEBUG("%p: maximum number of segments per packet: %u", > diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c > index abd8ce798986..6f4f351222d3 100644 > --- a/drivers/net/mlx5/mlx5_rxq.c > +++ b/drivers/net/mlx5/mlx5_rxq.c > @@ -1330,10 +1330,11 @@ mlx5_rxq_new(struct rte_eth_dev *dev, > uint16_t idx, uint16_t desc, > uint64_t offloads =3D conf->offloads | > dev->data->dev_conf.rxmode.offloads; > unsigned int lro_on_queue =3D !!(offloads & > DEV_RX_OFFLOAD_TCP_LRO); > - unsigned int max_rx_pkt_len =3D lro_on_queue ? > + unsigned int max_rx_pktlen =3D lro_on_queue ? > dev->data->dev_conf.rxmode.max_lro_pkt_size : > - dev->data->dev_conf.rxmode.max_rx_pkt_len; > - unsigned int non_scatter_min_mbuf_size =3D max_rx_pkt_len + > + dev->data->mtu + (unsigned int)RTE_ETHER_HDR_LEN = + > + RTE_ETHER_CRC_LEN; > + unsigned int non_scatter_min_mbuf_size =3D max_rx_pktlen + > RTE_PKTMBUF_HEADR= OOM; > unsigned int max_lro_size =3D 0; > unsigned int first_mb_free_size =3D mb_len - RTE_PKTMBUF_HEADROOM= ; > @@ -1372,7 +1373,7 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > * needed to handle max size packets, replace zero length > * with the buffer length from the pool. > */ > - tail_len =3D max_rx_pkt_len; > + tail_len =3D max_rx_pktlen; > do { > struct mlx5_eth_rxseg *hw_seg =3D > &tmpl->rxq.rxseg[tmpl->rxq.rxseg_= n]; > @@ -1410,7 +1411,7 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > "port %u too many SGEs (%u) needed to han= dle" > " requested maximum packet size %u, the m= aximum" > " supported are %u", dev->data->port_id, > - tmpl->rxq.rxseg_n, max_rx_pkt_len, > + tmpl->rxq.rxseg_n, max_rx_pktlen, > MLX5_MAX_RXQ_NSEG); > rte_errno =3D ENOTSUP; > goto error; > @@ -1435,7 +1436,7 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > DRV_LOG(ERR, "port %u Rx queue %u: Scatter offload is not= " > " configured and no enough mbuf space(%u) to cont= ain " > "the maximum RX packet length(%u) with head-room(= %u)", > - dev->data->port_id, idx, mb_len, max_rx_pkt_len, > + dev->data->port_id, idx, mb_len, max_rx_pktlen, > RTE_PKTMBUF_HEADROOM); > rte_errno =3D ENOSPC; > goto error; Also, here for the SCATTER check. Here, it is even an error. > @@ -1454,7 +1455,7 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > * following conditions are met: > * - MPRQ is enabled. > * - The number of descs is more than the number of strides. > - * - max_rx_pkt_len plus overhead is less than the max size > + * - max_rx_pktlen plus overhead is less than the max size > * of a stride or mprq_stride_size is specified by a user. > * Need to make sure that there are enough strides to encap > * the maximum packet size in case mprq_stride_size is set. > @@ -1478,7 +1479,7 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > !!(offloads & DEV_RX_OFFLOAD_SCATTER); > tmpl->rxq.mprq_max_memcpy_len =3D RTE_MIN(first_mb_free_s= ize, > config->mprq.max_memcpy_len); > - max_lro_size =3D RTE_MIN(max_rx_pkt_len, > + max_lro_size =3D RTE_MIN(max_rx_pktlen, > (1u << tmpl->rxq.strd_num_n) * > (1u << tmpl->rxq.strd_sz_n)); > DRV_LOG(DEBUG, > @@ -1487,9 +1488,9 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t > idx, uint16_t desc, > dev->data->port_id, idx, > tmpl->rxq.strd_num_n, tmpl->rxq.strd_sz_n); > } else if (tmpl->rxq.rxseg_n =3D=3D 1) { > - MLX5_ASSERT(max_rx_pkt_len <=3D first_mb_free_size); > + MLX5_ASSERT(max_rx_pktlen <=3D first_mb_free_size); > tmpl->rxq.sges_n =3D 0; > - max_lro_size =3D max_rx_pkt_len; > + max_lro_size =3D max_rx_pktlen; > } else if (offloads & DEV_RX_OFFLOAD_SCATTER) { > unsigned int sges_n; >=20 > @@ -1511,13 +1512,13 @@ mlx5_rxq_new(struct rte_eth_dev *dev, > uint16_t idx, uint16_t desc, > "port %u too many SGEs (%u) needed to han= dle" > " requested maximum packet size %u, the m= aximum" > " supported are %u", dev->data->port_id, > - 1 << sges_n, max_rx_pkt_len, > + 1 << sges_n, max_rx_pktlen, > 1u << MLX5_MAX_LOG_RQ_SEGS); > rte_errno =3D ENOTSUP; > goto error; > } > tmpl->rxq.sges_n =3D sges_n; > - max_lro_size =3D max_rx_pkt_len; > + max_lro_size =3D max_rx_pktlen; > } > if (config->mprq.enabled && !mlx5_rxq_mprq_enabled(&tmpl->rxq)) > DRV_LOG(WARNING,