From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <xuemingl@nvidia.com>, <dev@dpdk.org>, Martin Spinler
<spinler@cesnet.cz>, "Min Hu (Connor)" <humin29@huawei.com>, Yisen Zhuang
<yisen.zhuang@huawei.com>, Lijun Ou <oulijun@huawei.com>
CC: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, "Singh, Aman Deep"
<aman.deep.singh@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "Igor
Russkikh" <irusskikh@marvell.com>, Steven Webster
<steven.webster@windriver.com>, Matt Peters <matt.peters@windriver.com>,
Somalapuram Amaranath <asomalap@amd.com>, Rasesh Mody <rmody@marvell.com>,
Shahed Shaikh <shshaikh@marvell.com>, Ajit Khaparde
<ajit.khaparde@broadcom.com>, Somnath Kotur <somnath.kotur@broadcom.com>,
Chas Williams <chas3@att.com>, "Min Hu (Connor)" <humin29@huawei.com>, Nithin
Dabilpuram <ndabilpuram@marvell.com>, Kiran Kumar K
<kirankumark@marvell.com>, Sunil Kumar Kori <skori@marvell.com>, Satha Rao
<skoteshwar@marvell.com>, Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>, Sachin Saxena
<sachin.saxena@oss.nxp.com>, Haiyue Wang <haiyue.wang@intel.com>, "Marcin
Wojtas" <mw@semihalf.com>, Michal Krawczyk <mk@semihalf.com>, Shai Brandes
<shaibran@amazon.com>, Evgeny Schemeilin <evgenys@amazon.com>, Igor Chauskin
<igorch@amazon.com>, Gagandeep Singh <g.singh@nxp.com>, John Daley
<johndale@cisco.com>, Hyong Youb Kim <hyonkim@cisco.com>, Gaetan Rivet
<grive@u256.net>, Qi Zhang <qi.z.zhang@intel.com>, Xiao Wang
<xiao.w.wang@intel.com>, Ziyang Xuan <xuanziyang2@huawei.com>, Xiaoyun Wang
<cloud.wangxiaoyun@huawei.com>, Guoyang Zhou <zhouguoyang@huawei.com>, "Yisen
Zhuang" <yisen.zhuang@huawei.com>, Lijun Ou <oulijun@huawei.com>, Beilei Xing
<beilei.xing@intel.com>, Jingjing Wu <jingjing.wu@intel.com>, Qiming Yang
<qiming.yang@intel.com>, Andrew Boyer <aboyer@pensando.io>, Shijith Thotton
<sthotton@marvell.com>, Srisivasubramanian Srinivasan
<srinivasan@marvell.com>, Jakub Grajciar <jgrajcia@cisco.com>, Matan Azrad
<matan@nvidia.com>, Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Zyta Szpak
<zr@semihalf.com>, Liron Himi <lironh@marvell.com>, Stephen Hemminger
<sthemmin@microsoft.com>, Long Li <longli@microsoft.com>, Heinrich Kuhn
<heinrich.kuhn@corigine.com>, Jiawen Wu <jiawenwu@trustnetic.com>, "Tetsuya
Mukawa" <mtetsuyah@gmail.com>, Harman Kalra <hkalra@marvell.com>, Jerin Jacob
<jerinj@marvell.com>, Nalla Pradeep <pnalla@marvell.com>, "Radha Mohan
Chintakuntla" <radhac@marvell.com>, Veerasenareddy Burru
<vburru@marvell.com>, Devendra Singh Rawat <dsinghrawat@marvell.com>, "Keith
Wiles" <keith.wiles@intel.com>, Maciej Czekaj <mczekaj@marvell.com>, Jian
Wang <jianwang@trustnetic.com>, Maxime Coquelin <maxime.coquelin@redhat.com>,
Chenbo Xia <chenbo.xia@intel.com>, Yong Wang <yongwang@vmware.com>
References: <20210727034134.20556-1-xuemingl@nvidia.com>
<20210918123525.135129-1-xuemingl@nvidia.com>
<20210918123525.135129-3-xuemingl@nvidia.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
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: <PH0PR11MB5031C3737D5B24101429DB8295A19@PH0PR11MB5031.namprd11.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <xuemingl@nvidia.com>
> Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
<...>
> -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?