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 EF234A0C45; Tue, 21 Sep 2021 20:14:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61EBC4003F; Tue, 21 Sep 2021 20:14:25 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 508E94003C for ; Tue, 21 Sep 2021 20:14:23 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10114"; a="284449540" X-IronPort-AV: E=Sophos;i="5.85,311,1624345200"; d="scan'208";a="284449540" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Sep 2021 11:14:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,311,1624345200"; d="scan'208";a="613109037" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by fmsmga001.fm.intel.com with ESMTP; 21 Sep 2021 11:14:20 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 21 Sep 2021 11:14:20 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 21 Sep 2021 11:14:19 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 21 Sep 2021 11:14:19 -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.2242.12; Tue, 21 Sep 2021 11:14:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXY/XiJIo1wUHDhoiphBcYg2vh6ObkD6LBC0owZshSf/w55sQn3Jhcxg0lyxhHeigTZG5Zkju/uSm5YE0mJQfVHIVs23eRoa5hno94Y1XSzuAQPMrNvUp1sG8DVSSRdrR1CjsJVMovV1PZKMMl2oXSM+yi8ZQoL1p2pydFZ8whXv5+d1mG10i+bmN/SL14PBaMQZtiDTZKpLlCxNcdZlnnIs0BiMwcY1AaV+MYc7iuekyZrJZOQ5MZ+yIFC5JKAttCt48/sBjgO+PmB+v7n47PW2orOqI8qWF6TGewrsnw3cNbqvhk+oD3hRtrpDUhDEZpWbROaa3R1V2hN0bDl19Q== 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; bh=kfCZ9qrbI092c9A/vhxAcD7I2Alw2WIRYFp7wYmNy7Y=; b=J1pJT7/SaQDyzL/d+zIi43b3IF1hLIUC1AAoJZLE8TWIqM2wBl6dnhj4rE5Sb/Vvra37O4PgtG/A7JcuDcqfo1LQd746o2FjgdBOgCgWTjX3V/daQB5RvgW+Ufn6M+3qxXPL289gHlshyijf/lRjpNs7M3JGWNeAx3PVYVIJ06cRoR+w8unOMBhz6GslLPdg1fgU72B9YuQQ9Rjp24ATFHpzAuMrORSUbLTbZmYxbiWwibOhJ1HzizdSMaWmnA6wmZOLQZc+pvxngdTE2I3vzSpLY35ixaTi1dtLrVTBPOBTh667xTx1R1aZg9/2XmGUgd5qOTKQ8zufq3GQhxckFw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kfCZ9qrbI092c9A/vhxAcD7I2Alw2WIRYFp7wYmNy7Y=; b=Z5X4w8p2N/UHFsin/W3gU4ATZD3Pps4JzELUaLFcurQXxVXBakibLOzZ3Qi5VP5OxUNH92l51NXB2OflD+WusKActRUfACk7zkNXkB3UnbEzAaNVypKfAsSAYRXQGtJ3jaxB5rNM60X6yWmX9a4oClGL46+V5NanHkm7GIaULXE= Authentication-Results: vmware.com; dkim=none (message not signed) header.d=none;vmware.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5031.namprd11.prod.outlook.com (2603:10b6:510:33::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Tue, 21 Sep 2021 18:14:00 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4523.018; Tue, 21 Sep 2021 18:14:00 +0000 To: Xueming Li , , Martin Spinler , "Min Hu (Connor)" , Yisen Zhuang , Lijun Ou CC: Andrew Rybchenko , "Singh, Aman Deep" , Thomas Monjalon , "Igor Russkikh" , Steven Webster , Matt Peters , Somalapuram Amaranath , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , Somnath Kotur , Chas Williams , "Min Hu (Connor)" , Nithin Dabilpuram , Kiran Kumar K , Sunil Kumar Kori , Satha Rao , Rahul Lakkireddy , Hemant Agrawal , Sachin Saxena , Haiyue Wang , "Marcin Wojtas" , Michal Krawczyk , Shai Brandes , Evgeny Schemeilin , Igor Chauskin , Gagandeep Singh , John Daley , Hyong Youb Kim , Gaetan Rivet , Qi Zhang , Xiao Wang , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Yisen Zhuang" , Lijun Ou , Beilei Xing , Jingjing Wu , Qiming Yang , Andrew Boyer , Shijith Thotton , Srisivasubramanian Srinivasan , Jakub Grajciar , Matan Azrad , Viacheslav Ovsiienko , Zyta Szpak , Liron Himi , Stephen Hemminger , Long Li , Heinrich Kuhn , Jiawen Wu , "Tetsuya Mukawa" , Harman Kalra , Jerin Jacob , Nalla Pradeep , "Radha Mohan Chintakuntla" , Veerasenareddy Burru , Devendra Singh Rawat , "Keith Wiles" , Maciej Czekaj , Jian Wang , Maxime Coquelin , Chenbo Xia , Yong Wang References: <20210727034134.20556-1-xuemingl@nvidia.com> <20210918123525.135129-1-xuemingl@nvidia.com> <20210918123525.135129-3-xuemingl@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <5dbc3817-924b-9bdd-5176-f971ed63c493@intel.com> Date: Tue, 21 Sep 2021 19:13:42 +0100 In-Reply-To: <20210918123525.135129-3-xuemingl@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6PR1001CA0023.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::33) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6PR1001CA0023.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13 via Frontend Transport; Tue, 21 Sep 2021 18:13:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f0172936-b061-4cee-9665-08d97d2b95ef X-MS-TrafficTypeDiagnostic: PH0PR11MB5031: X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QjPyVkwP+42LMbVJlSZ/OoPTVVaOoeFQnNWFL3gpLOwwik67WluHbJcOjtLkw2eQz3cK1jvsM3aErvDUIlyM+sd437aAPgH6Qa9D1S2omS0le9AxR3cN6LAN/DBwKt+iLHEkRTg85ZjI9t+sI/gXq+DNHwEqwImcnYpAItPCxc1306RFsSVEN2JRifypQV3rglJw8NL+q08PtKVNkorMaveB3k07MJZr1eILoVShr/kVUlu09JOCuklBOdrT6OV+gHqEpuh+QofHQUaPdZAQ0z06d2nD6IdezmM5/vDxTRAy0NhnhgYOygC39RBOfphnxvl7VL7ckUi38N0jNB7wxY4Pb30v3KTMMaOrXJgWaB7OlC0401ikbn33h41YxwCd+COx38R7vHdDKmyJrRuo0cNF6JROH6SUzuLZaxqHKKx6jq9CnHbegbL3y1jJhAt4mKm7ssjis48E7RZc4TxNMJ26rGOu/q+jRmCVk7dG6IERXvrOieiRkLBkzNi3c6pG75jq562uzdyc+KiGvwPdYpa938f9hom2kdx/2FZvfFmIjkTiTj/7NWNiprHCn4Y3JmyiucgZCM4WyBOz5q1O4RIPYhK9trVfgdMSC4Jg9Uh/49e6ISaPUflM88WPssxyHihk0F86yGTcY6IsW1XjzE3ikTkaFdmfGN4+MnwnSmUiDlWfdDnci6JZG46ZQ13Z3MzsGLze88ZKBP+btrmfvg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(7366002)(31696002)(6666004)(53546011)(66556008)(5660300002)(7416002)(7406005)(83380400001)(8676002)(8936002)(36756003)(31686004)(66476007)(2616005)(508600001)(44832011)(86362001)(186003)(26005)(2906002)(6486002)(38100700002)(16576012)(956004)(54906003)(110136005)(316002)(4326008)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RTNCY0Z1VVN3NnhOZmYwemNaNUxXWHdwd0NpMW96dU1FbUFhTy82dU9jK3E0?= =?utf-8?B?MFVKSzlDQkNISUxaRkZTb09zZjZiWHNudTNObFN4bFFjWFBQSm9LL0RDWDBz?= =?utf-8?B?OHZLcmF5cEo5Q3dUbVh5aVA3dEJFc0hJaG14WTV6b2tBWllyeFJRc09IWEd1?= =?utf-8?B?YWVlc2xKSTQxZkdzRFZEN1ZIZmJzK2dodUw4U3JEQnVDc0VMek9NQ3NicW1S?= =?utf-8?B?Rkc1U1A0VWYzc0VqTGx3L1RXYnVwNHhvWEdYc0hqREZGQ09sVGtWTkdzeHl5?= =?utf-8?B?d1RnSW5yR0pQMjEzMVhXaUlKQnByZDd4UXhGSW5WME9iQm9nazBJNVB0MVRm?= =?utf-8?B?Vnh6OVk2eFVGMmk2bXAxLysvQStyaDJIa25VWjlMb1lFYWlpYXdnZzlmRHBZ?= =?utf-8?B?OHN4ekdQWVFUOTBHb2swcnppUDVsRDFoTU4xQjBpMGpJbnhYYzJPakVmU3BN?= =?utf-8?B?V2ZBVGdEcTBuTEdCNjV6WVdld0p3RjJZazB0cjRvdkxYTkN0dklaT0JvS2to?= =?utf-8?B?UkVubm9rQjhDOERWTCszdnpzd0QyOVhqTXpiWEdISERBbzczRWJhajBLcUQ5?= =?utf-8?B?Wnd3ZnEwU2Y1Vk40ckVTUGVyblpsMTdOb2dCQ0k3WEJoZDloSFNjTVpuUEFi?= =?utf-8?B?dEFRdk1sbU5zTU4reFV3d3FRcGhYRk5VNjJqMW0wM0RPSVUrd05zSXM0VTZI?= =?utf-8?B?UjFRRXZLdDZvSS8zWnVTOEFIczdkZmpOWjhDUGVsRnVKUkUzR0lnYlZGbG1H?= =?utf-8?B?L0ttMGVtSzdSWGo3c0RlZ09OblpYNUltQWZnTFFYS1hHZWlpY29kWmpROGV2?= =?utf-8?B?ZEVEVWdFS0N2YzhNZGpOd0pCVUhwVE9KcE1vRHhkeGd2UVRSd0MzdnQvVHFH?= =?utf-8?B?S1RYUGdLWTVoRm1ZZXBQWWp6VTFFQ0dqQnI1QU5sVllXcHRpRzZSaGZ1N0d6?= =?utf-8?B?Q2FwNGZqTFFUVDQxbDdFc3UyQ0QzaEVLNXh2UTFCdStySjYwNllSV2ZYcjZ6?= =?utf-8?B?U2Rhd0F6YTFoSXp3cDR4U2ZhdTV5Qk53Y2VYcWxpZndkNkcyMWV3VjlWcWl2?= =?utf-8?B?WUVvVUZ6Z0tDdVQ4NWVsZlc0Vk1vMlQwbmVWeFJYc1htVVR2UEw4TmJmeFhn?= =?utf-8?B?b2VkR0hBWTIxVEIvdHZnVzdTM2Vrb0hkaXFsa3BWS1h2SFBVNGZLZVg1dnZS?= =?utf-8?B?K2E1SnBWMzYwWVI4WkFjeE9yWFlRc1F6TC9tTkVwOUx3SVlBV0xaS0dZdUU5?= =?utf-8?B?ZjdsdmpORVlqZUJsNzBrS0M2bUpHNCt6WlRLelhKYlg5QVBpQmpYa2k1a29Z?= =?utf-8?B?Szlzby9wWXNIcEtpWG02ZXV1a3pOMmhJelQ2ckNaTE8zbGtaYmMvd2RYeUpL?= =?utf-8?B?UWlSWUxWTytGQXFFcFVPRWpRejBGc2lrYld5UnlMSk9YZlFWdkUwN0Zuc09a?= =?utf-8?B?elc1Qko5MzhWcDhCbm5UejRsdk9zZDZRYmdnSGpnMlcrNFc0QkIzVUwvS2Zx?= =?utf-8?B?czFaZUE4N25LNnpQYWJhRTdCaFNUTGs5TFhzMjhFZFIwYiszbHhrdWt4Vlc0?= =?utf-8?B?b1B2bzQ4amsrWXlselJGV3lOd1RMWEdmaXgySXdtSHI2ZFZvdURzL3lVcC9H?= =?utf-8?B?YnpBYWEyV3pXeWJ6eCtKamtKSmxpZDhFaEltVnpYY1JoNWtIRTVjSmhCVzV0?= =?utf-8?B?MWkxaUVmYVFyTTlLNkIraEhEUWJBYm5wRWp3WkhXMVhoVmJMaTl6NCtrL0Rt?= =?utf-8?Q?iQaZL73KfowbSaVRZqrNp1fMpVDZ8WSIG3wRCtJ?= X-MS-Exchange-CrossTenant-Network-Message-Id: f0172936-b061-4cee-9665-08d97d2b95ef X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2021 18:14:00.6389 (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: cBuMJpIDJuztmyMtr4Ndu/grSNe3MKtV15sEDgWe4177VyTjaHzzHc509R0JUr+KrmuBqbUoz+/0YHHVQB0CmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5031 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v5 2/2] ethdev: change queue release callback 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" On 9/18/2021 1:35 PM, Xueming Li wrote: > Currently, most ethdev callback API use queue ID as parameter, but Rx > and Tx queue release callback use queue object which is used by Rx and > Tx burst data plane callback. > > To align with other eth device queue configuration callbacks: > - queue release callbacks are changed to use queue ID > - all drivers are adapted > > Signed-off-by: Xueming Li > Reviewed-by: Andrew Rybchenko <...> > -void bnxt_rx_queue_release_op(void *rx_queue) > +void bnxt_rx_queue_release_op(struct rte_eth_dev *dev, uint16_t queue_idx) > { > - struct bnxt_rx_queue *rxq = (struct bnxt_rx_queue *)rx_queue; > + struct bnxt_rx_queue *rxq = dev->data->rx_queues[queue_idx]; > > if (rxq) { > if (is_bnxt_in_error(rxq->bp)) > @@ -273,6 +273,7 @@ void bnxt_rx_queue_release_op(void *rx_queue) > rxq->mz = NULL; > > rte_free(rxq); > + dev->data->rx_queues[queue_idx] = NULL; Similar question as did a few more times (I started to review from bottom), if this change is related to this set and if it should be fixed first before this patch. <...> > -void bnxt_tx_queue_release_op(void *tx_queue) > +void bnxt_tx_queue_release_op(struct rte_eth_dev *dev, uint16_t queue_idx) > { > - struct bnxt_tx_queue *txq = (struct bnxt_tx_queue *)tx_queue; > + struct bnxt_tx_queue *txq = dev->data->tx_queues[queue_idx]; > > if (txq) { > if (is_bnxt_in_error(txq->bp)) > @@ -83,6 +83,7 @@ void bnxt_tx_queue_release_op(void *tx_queue) > > rte_free(txq->free); > rte_free(txq); > + dev->data->tx_queues[queue_idx] = NULL; ditto. > } > } > > @@ -115,7 +116,7 @@ int bnxt_tx_queue_setup_op(struct rte_eth_dev *eth_dev, > if (eth_dev->data->tx_queues) { > txq = eth_dev->data->tx_queues[queue_idx]; > if (txq) { > - bnxt_tx_queue_release_op(txq); > + bnxt_tx_queue_release_op(eth_dev, queue_idx); > txq = NULL; For the 'txq = NULL', can the intetion be "eth_dev->data->tx_queues[queue_idx] = NULL", since above 'bnxt_tx_queue_release_op()' adds this assignment. Otherwise it looks unnecessary. <...> > @@ -2421,7 +2421,6 @@ static struct eth_dev_ops dpaa2_ethdev_ops = { > .rx_queue_setup = dpaa2_dev_rx_queue_setup, > .rx_queue_release = dpaa2_dev_rx_queue_release, > .tx_queue_setup = dpaa2_dev_tx_queue_setup, > - .tx_queue_release = dpaa2_dev_tx_queue_release, This should be removed in previous patch. <...> > @@ -1536,7 +1536,8 @@ hns3_fake_rx_queue_config(struct hns3_hw *hw, uint16_t nb_queues) > /* re-configure */ > rxq = hw->fkq_data.rx_queues; > for (i = nb_queues; i < old_nb_queues; i++) > - hns3_dev_rx_queue_release(rxq[i]); > + hns3_dev_rx_queue_release > + (&rte_eth_devices[hw->data->port_id], i); I think this should be done without driver accesing the global 'rte_eth_devices' array. This may require more help from driver maintainer, and perhaps wrapper functions can be used for the driver for now and maintainer can update it later, if agreed with the driver maintainer. <...> > void > -i40e_dev_rx_queue_release(void *rxq) > +i40e_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + i40e_rx_queue_release(dev->data->rx_queues[qid]); > +} > + > +void > +i40e_dev_tx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + i40e_tx_queue_release(dev->data->tx_queues[qid]); > +} > + Is there any specific reason to not update driver but add wrappers for it? <...> > +void > +ice_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + ice_rx_queue_release(dev->data->rx_queues[qid]); > +} > + > +void > +ice_dev_tx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + ice_tx_queue_release(dev->data->tx_queues[qid]); > +} > + Is there any specific reason to not update driver but add wrappers for it? <...> > diff --git a/drivers/net/nfb/nfb_rx.c b/drivers/net/nfb/nfb_rx.c > index d6d4ba9663..3ebb332ae4 100644 > --- a/drivers/net/nfb/nfb_rx.c > +++ b/drivers/net/nfb/nfb_rx.c > @@ -176,9 +176,10 @@ nfb_eth_rx_queue_init(struct nfb_device *nfb, > } > > void > -nfb_eth_rx_queue_release(void *q) > +nfb_eth_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > { > - struct ndp_rx_queue *rxq = (struct ndp_rx_queue *)q; > + struct ndp_rx_queue *rxq = dev->data->rx_queues[qid]; > + > if (rxq->queue != NULL) { > ndp_close_rx_queue(rxq->queue); > rte_free(rxq); Unrealted with this patch, but this code follows as below, why setting 'rxq->queue = NULL' after 'rxq' is freed? This needs to be fixed separately ( 1 if (rxq->queue != NULL) { 2 ndp_close_rx_queue(rxq->queue); 3 rte_free(rxq); 4 rxq->queue = NULL; 5 } Same for 'nfb_eth_tx_queue_release()' <...> > @@ -556,7 +558,8 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev, > > if (tz == NULL) { > PMD_DRV_LOG(ERR, "Error allocating rx dma"); > - nfp_net_rx_queue_release(rxq); > + nfp_net_rx_queue_release(dev, queue_idx); > + dev->data->rx_queues[queue_idx] = NULL; Althoug I agree on NULL assignment, not sure if it is related for this patch. It seems this assignment was missing and this patch is fixing it, independent from API change. I did similar comment for other drivers, as a generic comment, what about fixing them in a separate patch first, and do the API convertion later? <...> > @@ -248,16 +248,18 @@ otx_ep_rx_queue_setup(struct rte_eth_dev *eth_dev, uint16_t q_no, > * Release the receive queue/ringbuffer. Called by > * the upper layers. > * > - * @param rxq > - * Opaque pointer to the receive queue to release > + * @param dev > + * Pointer to the structure rte_eth_dev > + * @param q_no > + * Queue number > * For rest of the drivers, comments updated as following, I suggest keeping consistent wording on all drivers: @param dev Pointer to Ethernet device structure. @param q_no Receive queue index. <...> > > +static void > +qede_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + qede_rx_queue_release(dev->data->rx_queues[qid]); > +} > + > +static void > +qede_dev_tx_queue_release(struct rte_eth_dev *dev, uint16_t qid) > +{ > + qede_tx_queue_release(dev->data->tx_queues[qid]); > +} > + Technically this wrapping can be done for all drivers, I can see it simplifies the implementation for this patch but not sure if it is best for the driver. And since in other drivers implemenation is changed instead of this wrapper, is there a specific reason to not update the implementation for 'qede'? <...> > @@ -872,6 +871,7 @@ nicvf_dev_tx_queue_release(void *sq) > txq->txbuffs = NULL; > } > rte_free(txq); > + dev->data->tx_queues[qid] = NULL; This may be required but seems not related to changing release API parameters ('eth_dev_txq_release()' already sets txq[id] to NULL). And if this change is required, same can be required for 'nicvf_dev_rx_queue_release()', what about dropping this change from set and make a separate patch for it if required?