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 D002DA0C4B; Fri, 15 Oct 2021 13:46:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 91F5B411CB; Fri, 15 Oct 2021 13:46:50 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 27639410F1 for ; Fri, 15 Oct 2021 13:46:47 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10137"; a="288763999" X-IronPort-AV: E=Sophos;i="5.85,375,1624345200"; d="scan'208";a="288763999" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2021 04:46:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,375,1624345200"; d="scan'208";a="716491445" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by fmsmga006.fm.intel.com with ESMTP; 15 Oct 2021 04:46:46 -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; Fri, 15 Oct 2021 04:46:46 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) 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; Fri, 15 Oct 2021 04:46:45 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Fri, 15 Oct 2021 04:46:45 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) 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; Fri, 15 Oct 2021 04:46:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JVWGaQozh8FkbHJj5FwxsHBUaPcxsYWcJMGXJ01BtkX+qb//7qYd08oS12IBOWnBGOY+/QQ5Ta4m6BgKvzJHQBI7DdzHzWR9aUCRhWT9jchTu5DvNgYBJk29UiDC4c+fH6lHGEsQkPkgsml7COqIG+wiNtIQXCsextu44JPhL+F8v5dPe9ZtaKKWYkDtYsu0NHw1Li+vLhBLWTyvF5MWKo0ZbQdFP/a4iYMD67Z9pniPOlRrcMqeGVaXjrH98slCpcQyHNMENuQjmyrCDFfKnyttUZNww+4KavFYfz9WnSRFG/le+L193OOjGFmdDbiHpgyHy66ESyEVeWOkvdMI2g== 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=1x66j8zn79C4/Q8oxErayYbszW6Rx4xx1D3RSpNu4Bo=; b=cQvOUyk2Qbj43uM14Wj55AjDvpfRe50gVXMvNO3J4Hcy8GGndER5dDxQv1AmzgAxS55mZaBVwMA09tOdsziPcF72NuwQe6kEZIw/iO7Ow3tsLGuApEAa6/Om7cAkyOV3Lx2oljGRK10i+C3IV4IddGRvkwuY2OhH8wNPRJ8zFEFe3+h2Al5dXnnhp2Iq7qPfd4GOHf+EC6DEJePl3dcc+8rKdNoEXDEJOp87pK/Mi/PQwIHf4/FstI/tShIrU9HRDVwUygRxw7sQoaqP81hkBUWlY8jHBQUnK8tGuBG3AfeWwfGOENgwVZPK/q3XJie/JfXE268Mr2kWTaHGmeKNSA== 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=1x66j8zn79C4/Q8oxErayYbszW6Rx4xx1D3RSpNu4Bo=; b=VoMpPxKQG5+kiOSy86mA9dHUmXNDfNJu8vxj4ySkMT0xhSpbdLhcVY3mXG5PirjhlkCwFFyjFAC+7BRP9VrbQUpGsu+yEYMVKJGbqCxCIBaoQxOFW1UkaZ5KpvodqDs5OZ+bn2F7Qw0T/7Du2Y/pcwGvRJZ1FrudAUe0/d8YeUk= Authentication-Results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB4789.namprd11.prod.outlook.com (2603:10b6:510:38::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15; Fri, 15 Oct 2021 11:46:41 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c%5]) with mapi id 15.20.4608.017; Fri, 15 Oct 2021 11:46:41 +0000 Message-ID: <0f16daab-6040-2973-03f3-8bc4e954c84e@intel.com> Date: Fri, 15 Oct 2021 12:46:34 +0100 Content-Language: en-US To: Dmitry Kozlyuk , "dev@dpdk.org" , Andrew Rybchenko , Ori Kam , Raslan Darawsheh CC: NBU-Contact-Thomas Monjalon , Qi Zhang , "jerinj@marvell.com" , "Maxime Coquelin" References: <20211005005216.2427489-1-dkozlyuk@nvidia.com> <20211005005216.2427489-3-dkozlyuk@nvidia.com> <9a9ab2b5-89d1-1653-9022-ebf1b8a86902@intel.com> From: Ferruh Yigit X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB9PR02CA0023.eurprd02.prod.outlook.com (2603:10a6:10:1d9::28) 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 DB9PR02CA0023.eurprd02.prod.outlook.com (2603:10a6:10:1d9::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16 via Frontend Transport; Fri, 15 Oct 2021 11:46:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7490022c-3e24-451e-e521-08d98fd1742b X-MS-TrafficTypeDiagnostic: PH0PR11MB4789: 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:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9pThV4BNluQ4x8Gs5HyiEPlReqyZA1LhGQTzLFKonZHJ8SEyG1trNRgyFrwe6ds4l40ujSt4fcoHmgkQCwBdypL/n59VBmr9ZL587M9iME5L5XQZgPakESW6Mi/bTXH88LBG877d91rdjG9DeQP8Sv1n0HkqrJ56HNnnMF9VJwd1WY9tkWcXLFkV1UJtE0JEdaYRdaHrDrmv0GBt8reJwN0admWB4WZ+mIwQSSqjFa++9ib4czLUsbNXQZKHXgHFr5AViRTzKXGmPRo9PSKgTL/knCMr09L2H+zW2wTkArnzQg7kkFgJNJ2rUc0r9lqw+sA5wQy8U3kvTacSHrMz9k/tURUyE8iu1GRQBgiucN95r24isuCPOGMpaBTzyEzIYHX4FmWATX/oUILMWvMHT4lV2WlqsQC9btSHhpyQkRWIafr/HIbgCwVtq1sLM9wmEm4UgPkPYRfRwTJugtvshX7xAtwnAyppEWdczObCSMCwtd/aBdPIuTu/Vrj2gkvfBsishERSBSvvm6BgXBzhtV7OflR88NBJ4EhDscUnoZ9y+RZwaMWhLEa7fUkTbQXwan6QziK/jYWCiKnrEHI1FcNvS+WKu0PKOIpYgU684af/7W+9vNyAJ2A1MgVHujsfxhLP2F654LbLedq6iH55JjKhMFzkRzqzaTedl0K4i4q+Ln56uVXL487mA/mpeu0guPoo+Z1UfJmqt3ZxGYKe+uZ7tLyLHCugo5avpFS1DcZBpW9s5OCFkPZVcxKo+1HxZSkxj9DTeRalI97r9WDCguM/l1EiPSkDBn0GRkE1y4fxeiKo9PN3IzYj9bQVbHFBzDpq1gNzmrtHHxbhLp9ZrQ== 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:(366004)(8676002)(5660300002)(54906003)(508600001)(2616005)(66476007)(66556008)(36756003)(956004)(66946007)(110136005)(53546011)(82960400001)(6486002)(26005)(4326008)(966005)(316002)(16576012)(186003)(2906002)(86362001)(31696002)(45080400002)(8936002)(6666004)(31686004)(83380400001)(38100700002)(44832011)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NWpoTitRTTRVdk1ZNFh4SGVYNE9rRWJrQmZpQmEyMDd2NW40bFhRQTJiZHp2?= =?utf-8?B?TkxQUzgzVG1tR1Rzb1h4QjVGN280ZjFUZnlDV3crbWhGUGtZd3FpZnZHZTYy?= =?utf-8?B?Zm9PSkNMQkxKb3BjQnBvbHY2WlhDQ3dESU5rdkJUamhnSTMySVVHbFZwQVkw?= =?utf-8?B?cDhRc21BYjNBaU9YaDBwSDJLNnBIUEF5Qk9mVjJGRFgyRzdoTktEWmd3NWV6?= =?utf-8?B?OTR1YnU5bFdyaFR2Mk12czFQZ3B0b3NlZEZhS0ZaRVdCWUY0VzcrbkdGbjlk?= =?utf-8?B?bmNWZjF0UzBkTkZieU9GYmRJRnB3SXVqOGppaE9rRHhNaENmUjZWUEphYUNj?= =?utf-8?B?Y1dGYTM1bnRiOVZ6YXFxQkMvMDY4aTdzdUJxNFNQdmtHR0l0dHkxNUdWSkZC?= =?utf-8?B?ejUzOFUvc2Zpbkp3NmZhWFJHK0NGcXdPc0ZjTXg2aGwxN1ozTlluYVdLSno4?= =?utf-8?B?ejcvN1ZvZWZGMEl4ZlBFUmx0NDRSYWNLNzByaTd4YlJ0emx5ZlovbWNNQTBE?= =?utf-8?B?OHZ1TzJaUWVkMmwyK2hzMnVUQWRVNklWYTg4SVI2blQ2TjJ2NFA1YTl2Wm55?= =?utf-8?B?dDNETHR3dlE0NjBZNjgvTGNvUjUvY2lEL3p4bkJ5WW1sRzdCdzdSTWdnc0Fz?= =?utf-8?B?NlhxQXZMTzFPOG05YmpNMllNNG9idEd3Rlp4QUNSZ3c0OWdvSlFSSFUwR05r?= =?utf-8?B?eXJUS21KMlVhV2hOaVhJWUVyd2FqZjE4NFJIeXB5NUs2V0NhcFZLdnJBMUhD?= =?utf-8?B?TTF4Zlk2YktBS3JCVjVhbFJnTnhQN2dRVFZvTCs0bjhielgzb1E0cmhhU1cr?= =?utf-8?B?Yml0cGhkTUFEeDFtYzVVR3FFbjdEZVBLZEtSeVhwUE9DRDhMenk3Z20rRDFR?= =?utf-8?B?b2hjQk5QWnRMeDlyZm4xcldNeFU3bXNFRDJVb2FxWHhnY0FuMFVkSFRGdkFx?= =?utf-8?B?NTFuby9IZGhIRnVhTlFueGpPMHNTQ0l2c1h0Q3FoSWxNd3c5RVgxL2xsbE9h?= =?utf-8?B?ajE0WnlFUGxvWjNRa01ienlGRlhEcVRiSURKR3RyWXNsbnMrMTlpZmZaSXYv?= =?utf-8?B?Nno2elk2dzZ4MmlyZTlKdll4WlB5bzJab3R0Wm5namVKMWlYQ0gxRTh3S0l6?= =?utf-8?B?Vk1aNVJsa0o1bWJmcE9SVGNEZ2YwMXF1YVoveXVNK2ZlclV6cVdWeTQyMERO?= =?utf-8?B?NU5SVFJCN0p5ZmhtVGFHV1hlU2w5RjNPVWZqUVdhSG9KYTBPNnhKNnRyMFND?= =?utf-8?B?bUN6VHg4S1EyOTJ4cURSb0xvbm5UZnkvbVNwUVB1MWo0M2Z5TzNRckg4dnVJ?= =?utf-8?B?Zk9UekxFWnlGVDN6YllGaWNRT2dWbEZLcTdrcDZITFJtYWw4bURET3JHMzdN?= =?utf-8?B?QitiNnl2aDZqMm56eHBTcUxCbU5TbGkrMTZlVmo4U3VvTW5haGt2UjB6dzMw?= =?utf-8?B?MytCcC9MT0Z3bDZwOU94cWY2ZlhMVEkwUzFkWVErVUt4Rzc1dEljaGxaYjRl?= =?utf-8?B?SWtSL1llRTUwRHlza0dIRGZKTDVBSmwwMTBhR3Uzei9tN3R3dFFmZGFHRWRO?= =?utf-8?B?MnMzcktYVERIc3prcEZqLzdUb2ZQeGc3UjdZMkpZYnlFRFlLOC9NMjhVanpR?= =?utf-8?B?VXNVZG9tb3ErK01GWXpaM3AxUXlLY3lQNnhKOUowbEZuNXo4RXR6YXdyL293?= =?utf-8?B?eHUrOHZDbkk1OGQrRzM4MGdQUFlWNmovaE9OUXBWbDZYSUlrOTMxZFdWbjF6?= =?utf-8?Q?dtHsZZjYlH6zY4hrKBpjAK7rra65Ss4waxKQvMW?= X-MS-Exchange-CrossTenant-Network-Message-Id: 7490022c-3e24-451e-e521-08d98fd1742b X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2021 11:46:41.2025 (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: 3erLJAZ7dDFGXOPFWbwBbXpxzSz53snWBTKOEPC81VJh8NhBXSVF63HFV99U/mL7dahaJg7y5VtU/K3iPD9VuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4789 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add capability to keep shared objects on restart 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 10/14/2021 10:45 PM, Dmitry Kozlyuk wrote: >> -----Original Message----- >> From: Ferruh Yigit >> Sent: 14 октября 2021 г. 16:47 >> To: Dmitry Kozlyuk ; dev@dpdk.org; Andrew Rybchenko >> ; Ori Kam ; Raslan >> Darawsheh >> Cc: NBU-Contact-Thomas Monjalon ; Qi Zhang >> ; jerinj@marvell.com; Maxime Coquelin >> >> Subject: Re: [PATCH 2/5] ethdev: add capability to keep shared objects on >> restart >> >> External email: Use caution opening links or attachments >> >> >> On 10/13/2021 9:32 AM, Dmitry Kozlyuk wrote: >>> This thread continues discussions on previous versions to keep >>> everything in the thread with final patches: >>> >>> [1]: >>> http://inbox.dpdk.org/dev/d5673b58-5aa6-ca35-5b60-d938e56cfee1@oktetla >>> bs.ru/ >>> [2]: >>> http://inbox.dpdk.org/dev/DM8PR12MB5400997CCEC9169AC5AE0C89D6EA9@DM8PR >>> 12MB5400.namprd12.prod.outlook.com/ >>> >>> Please see below. >>> >>>> -----Original Message----- >>>> From: Dmitry Kozlyuk >>>> Sent: 5 октября 2021 г. 3:52 >>>> To: dev@dpdk.org >>>> Cc: Dmitry Kozlyuk ; Ori Kam ; >>>> NBU- Contact-Thomas Monjalon ; Ferruh Yigit >>>> ; Andrew Rybchenko >>>> >>>> Subject: [PATCH 2/5] ethdev: add capability to keep shared objects on >>>> restart >>>> >>>> From: Dmitry Kozlyuk >>>> >>>> rte_flow_action_handle_create() did not mention what happens with an >>>> indirect action when a device is stopped, possibly reconfigured, and >>>> started again. It is natural for some indirect actions to be >>>> persistent, like counters and meters; keeping others just saves >>>> application time and complexity. However, not all PMDs can support it. >>>> It is proposed to add a device capability to indicate if indirect >>>> actions are kept across the above sequence or implicitly destroyed. >>>> >>>> In the future, indirect actions may not be the only type of objects >>>> shared between flow rules. The capability bit intends to cover all >>>> possible types of such objects, hence its name. >>>> >>>> It may happen that in the future a PMD acquires support for a type of >>>> shared objects that it cannot keep across a restart. It is >>>> undesirable to stop advertising the capability so that applications >>>> that don't use objects of the problematic type can still take advantage >> of it. >>>> This is why PMDs are allowed to keep only a subset of shared objects >>>> provided that the vendor mandatorily documents it. >>>> >>>> If the device is being reconfigured in a way that is incompatible >>>> with an existing shared objects, PMD is required to report an error. >>>> This is mandatory, because flow API does not supply users with >>>> capabilities, so this is the only way for a user to learn that >>>> configuration is invalid. For example, if queue count changes and RSS >>>> indirect action specifies queues that are going away, the user must >>>> update the action before removing the queues or remove the action and >>>> all flow rules that were using it. >>>> >>>> Signed-off-by: Dmitry Kozlyuk >>>> --- >>>> [...] >>> >>> Current pain point is that capability bits may be insufficient and a >>> programmatic way is desired to check which types of objects can be >>> kept across restart, instead of documenting the limitations. >>> >>> I support one of previous Ori's suggestions and want to clarify it [1]: >>> >>> Ori: "Another way is to assume that if the action was created before >> port start it will be kept after port stop." >>> Andrew: "It does not sound like a solution. May be I simply don't know >>> target usecase." >>> >>> What Ori suggests (offline discussion summary): Suppose an application >> wants to check whether a shared object (indirect action) or a flow rule of >> a particular kind. It calls rte_flow_action_handle_create() or >> rte_flow_create() before rte_eth_dev_start(). If it succeeds, 1) it means >> objects of this type can be kept across restart, 2) it's a normal object >> created that will work after the port is started. This is logical, because >> if the PMD can keep some kind of objects when the port is stopped, it is >> likely to be able to create them when the port is not started. It is >> subject to discussion if "object kind" means only "type" or "type + >> transfer bit" combination; for mlx5 PMD it doesn't matter. One minor >> drawback is that applications can only do the test when the port is >> stopped, but it seems likely that the test really needs to be done at >> startup anyway. >>> >>> If this is acceptable: >>> 1. Capability bits are not needed anymore. >>> 2. ethdev patches can be accepted in RC1, present behavior is undefined >> anyway. >>> 3. PMD patches will need update that can be done by RC2. >>> >> >> Hi Dmitry, >> >> Are you planning to update drivers yourself on -rc2? >> Or do you mean PMD maintainers should update themselves, if so do they >> know about it? >> >> If the ethdev layer is updated in a way to impact the drivers, it should >> be either: >> - all drivers updated with a change >> or >> - give PMDs time to implement it on their own time, meanwhile they can >> report their support status by a flag >> >> We had multiple sample of second case in the past but it is harder for >> this case. >> >> For this case what about having three states: >> - FLOW_RULE_KEEP >> - FLOW_RULE_DESTROY >> - FLOW_RULE_UNKNOWN >> >> And set 'FLOW_RULE_UNKNOWN' for all drivers, to simulate current status, >> until driver is updated. > > Hi Ferruh, > > Indirect actions are only implemented by mlx5 PMD, > the patches will be in RC2. > If we don't use the flag as per the latest suggestion, > nothing needs to be done for other PMDs. > Flag can as well be kept with the following semantics: > 0 => indirect actions are flushed on device stop > 1 => at least some indirect actions are kept, > application should check types it's interested in > My concerns is related to the 'flow rules', not indirect actions, the patch mentions capability is for both of them. > Introducing UNKNOWN state seems wrong to me. > What should an application do when it is reported? > Now there's just no way to learn how the PMD behaves, > but if it provides a response, it can't be "I don't know what I do". > I agree 'unknown' state is not ideal, but my intentions is prevent drivers that not implemented this new feature report wrong capability. Without capability, application already doesn't know how underlying PMD behaves, so this is by default 'unknown' state. I suggest keeping that state until driver explicitly updates its state to the correct value. But having below list is good, if you will update all drivers than no need to have the 'unknown' state, but updating drivers may require driver maintainers ack which can take some time. Can you please clarify what is you plan according PMDs, will you update them all, or will you only update mlx5 in -rc2? And what is the exact plan for the -rc2 that you mention? > Here's what I understood from the code, assuming there are no bugs > Like allowing to stop the port and keep dangling flow handles: > > bnxt flush > bonding depends > cnxk can't figure out > cxgbe keep > dpaa2 keep > e1000 keep > enic flush > failsafe depends > hinic flush > hns3 keep > i40e keep > iavf keep > ice keep > igc keep > ipn3ke keep > ixgbe keep > mlx4 keep > mlx5 flush > mvpp2 keep > octeontx2 can't figure out > qede keep > sfc flush > softnic flush > tap keep > txgbe keep > > Currently one flag would be sufficient to describe PMD behavior: > they either keep or flush the flow rules. > If there are indeed no exceptions, which maintainers should confirm, > I can add flag reporting myself. >