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 B7B1DA0C45; Thu, 25 Nov 2021 16:14:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7342640DFD; Thu, 25 Nov 2021 16:14:19 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id DA18540DF5 for ; Thu, 25 Nov 2021 16:14:17 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10179"; a="234259648" X-IronPort-AV: E=Sophos;i="5.87,263,1631602800"; d="scan'208";a="234259648" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Nov 2021 07:14:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,263,1631602800"; d="scan'208";a="457895283" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga006.jf.intel.com with ESMTP; 25 Nov 2021 07:14:16 -0800 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) 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; Thu, 25 Nov 2021 07:14:16 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 25 Nov 2021 07:14:15 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) 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; Thu, 25 Nov 2021 07:14:15 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Thu, 25 Nov 2021 07:14:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C5vRoiFsuAY9s8vlntriyWcaOhxacBguh4e1qgBMtCTqiQ0tcUpgNwoVgtR65y8HU78FDjFhddSxnGhel6Oy2qGW66XJxeD1OQnT5rdsgjM69FGNxMGTDBQu2n3h+rOVzK52YuyI7OjbM8CupoH3wVzc5r4/uPK446N2q3vg3j6OCuLOIUS0FXb8/0kL1bYSwXKblcoscGmYNJ+oZQ4ITYmN2BtVuq4sXGcYPnUsWDjbwZ7cgXCvXB4Hzf7Y0dHG4zkOPqS431lKHxZ2cVLOrZ+jOT8tlk/eFarQbo69wzDZdG5FIj1dI49yeuvJ1b6Bq9/sKo3mkYSOw+7qe3Px/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=9GrQLjo8Kxn0+tCnUwFPUSrNvnT+sk9twSF2Ahg5POA=; b=WPzdh2amjlTNOCG0L2vG0VG9WDFWmkQPxxPMzgxZfm2lS+BkQbS/OAkIOGpBvcNEunWkgwlavwKI25QbpHuy4HekrQdkNMm6iGka7IOKZ2kODZmD2l6sE++idNMSN+0q2l9InNx4HjcU1JyQpzJsvNfXGy817f0mnJLPK80VTSfWDpHD24koaQc7jPjm/KMdMp3BXVY6hd18aQu0hqbjezIxYdm06VXc4aKE8UfiQLxQiiFrM4wY+5Un8JDRkYDuAxSfuQkdMpnLIDvoBmI689RIIcBc9pMSyo7jhilgHpUkLxfWfmQE5LgbNhHn3KLDL3Z/AhUHP443VlpwLbJj6g== 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=9GrQLjo8Kxn0+tCnUwFPUSrNvnT+sk9twSF2Ahg5POA=; b=chAQZllFdHir+A/hN3+zvGbOhPXpYjCbBufwpXlxmX9eKvlwA6O48xQ8/NhKLbY/NM8pJirdKFEeDIJIrAbrjpOfu+fTFLdxIZIR3MSRmrINnVr0VXfrngl8Mw2rlIHzTiUmmJ2NPbGkHlE62ptUkYvNs+5in0WbcH3u1VeT2Os= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5095.namprd11.prod.outlook.com (2603:10b6:510:3b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.21; Thu, 25 Nov 2021 15:14:14 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bc5f:31a7:10ad:443c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bc5f:31a7:10ad:443c%5]) with mapi id 15.20.4690.030; Thu, 25 Nov 2021 15:14:13 +0000 Message-ID: Date: Thu, 25 Nov 2021 15:14:07 +0000 Content-Language: en-US To: Slava Ovsiienko , Andrew Rybchenko , Ajit Khaparde , Somnath Kotur , Rahul Lakkireddy CC: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "dev@dpdk.org" References: <20211123075940.5521-1-viacheslavo@nvidia.com> <20211124153756.12198-1-viacheslavo@nvidia.com> <0e5753c9-85c3-1dc1-69d8-460cb0a7b5a4@intel.com> From: Ferruh Yigit Subject: Re: [PATCH v3] ethdev: deprecate header fields and metadata flow actions X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB8PR06CA0043.eurprd06.prod.outlook.com (2603:10a6:10:120::17) 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 DB8PR06CA0043.eurprd06.prod.outlook.com (2603:10a6:10:120::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.22 via Frontend Transport; Thu, 25 Nov 2021 15:14:12 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d45b8692-cf92-4b81-3e45-08d9b0263d6e X-MS-TrafficTypeDiagnostic: PH0PR11MB5095: 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: 85ZSkVG7hzqdfAq500nC+/9m9N3HtcGheIBeZscqeKvZTPN42MReuUvSkBgY7a8ot97BMhXh6lazVkEt6R8MaHQz58x0L3GJd8opGuY/QqXmhV2kDe4G1DkNNRHP4nMf1UoR3sjVewE8wLmHEUKq4oIPIbAojAHcYpDiUL6jcyDjl0ovYkGfw/DV8PxRup6ycwgyX4+B9qzuCsF2aStC4whzUf4yJBu5qVq20iCxbr/YifCRGombgWeRJEfvCY1D7vLdTqrUKvpiDt2ESu70jyZci7pwdTYKyfhAQzhsGX5Lt9581ObbbMlpBoqz3eHhmgn/0PSVJl/eWa1TaIvdayWLr44F+4TSPnnuOCNZ0TAy6XH5zxajgcsr+QeRDoKI4tc2m+NG6fOX7NHseFB6H2s/eebZeSNODn/h4GMIquhyUCQ4E+HOXz6xG1S2IiSASJge2cKC/A8Y5JCbJLSL7WHeb5lL0PuDCdh7jiT34ybL47rRuKJtIhl4+sP6B2OEXyIZ33Kc9KlI4+6oIxguFVIV8pAsrtO4kDIvCNWY8KI1dTW4Z0fwwRkvmY40fWcAdRo8WTmh+B0JniJuD2PdCwXo4vLDUXwPvVqrN1EybNr1VVB+i17ELmV//ndCeJJY0dnFd2Dhkoc4HVGfmUVYl3anPmujiSp3PXU0kgnC6HPb0pEy0in5lccgEPDF6D+GGOY/MwNbeHEfoOW/ESAJ12dXM4YvDFm10YUyxnuu+vU= 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)(6666004)(26005)(38100700002)(36756003)(86362001)(6486002)(53546011)(508600001)(5660300002)(2906002)(31686004)(83380400001)(82960400001)(316002)(110136005)(16576012)(54906003)(8936002)(8676002)(66946007)(2616005)(4326008)(44832011)(31696002)(956004)(186003)(66556008)(66476007)(21314003)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V1E0Ui9QMk9GYTNDbjdjV2pzNzVLcDgzcTJacHNNamRLTkw0RkJ2ZFBXL1RC?= =?utf-8?B?SGE3WWo0UjFZOTM5MzFJb0oxZjFKVnZmV2cyUkpycFhUaWtDS3dzOVNrUmh0?= =?utf-8?B?czFaeXNzZnhYQllyWTNVdyttcEM4TkNGNkNtdXN5aEVtSWVaZWUxMFlXQ090?= =?utf-8?B?TCtDVUVkWlk4V2tKN0pjR21SUHFzTzR5L0M0RW9jd0p4MmR1d0ZQQk1WaFNS?= =?utf-8?B?bjlTNjB5bTIydXNxaXB1dVA5L08za01iVnd4N2xZaHhUeFRKNUk1Rk1nWW1X?= =?utf-8?B?UHBROUZ4ZzBQS1VqdmxRL2VBMi9KZERQYUY0bktnUkJmT3Q4NDFVb2VvaFBE?= =?utf-8?B?ZVBPTDI3N3hkMDNtbk1pVGRiMkk3b0lwWmpISGVKWkZyS2dvY2hXRWl3K1Yv?= =?utf-8?B?SXc0UklBazRJMVpPVUpEZEtja2RDbStyb3NlMWtsZVIrU3VSenRzZzd4Tmpv?= =?utf-8?B?SUNQNXR2UjlRdWliemUxallsc2tHVVZyUVBkUkJuV2txeEJXVE9VdWdsMXJj?= =?utf-8?B?UTh1TTBvSTNwcVd4VE1mOXIySFhhRzJEd0orU2U0UE9DcVEyR1F5U1hWSE8z?= =?utf-8?B?ZGc0RWV5bDZHcDZxRU1ldzVVRkpKbHpydVJnYVZ3dE1CZWQ0eXlqTGF0by9O?= =?utf-8?B?STdTREJBbTJrcHREdTYrS2t2elg5cHVHdUlDeFJyN0Y2ZiszaGhNcWhWbUxj?= =?utf-8?B?WVQrUXlmS2xEK01NVkhWZmdTZFByVk9lYkdYc04rMUh6bDhmNUdtYWM4WTRT?= =?utf-8?B?YS9yb1hJcUM0dmtJOFFscGs5SFJWOU1JN3RXSVhlVEdyd3JlTlpBemxjcjJ4?= =?utf-8?B?M1dEODlBUDg3NWlHaXh3aHBjdlE5bWZMN1NKNmY4ZWRKSUJibUFmTWRzYlZC?= =?utf-8?B?M1VxcUVnYlNXVnc1NGx4dWJSd1h6MldqVnpKa3YwenhidU9mM3o1aXpQV1Yx?= =?utf-8?B?UGt0M2NFVk5CZ0xlMVBuZHJDM1dlZ1dkYno0bjUzamdhMzVBYVc1elJQTlJN?= =?utf-8?B?YTNEcW9PNG1ZaUNXNnZhcVVIdVMrR3U3blRmdDFpUkNCbTJyV2cxMDF1S3Uw?= =?utf-8?B?Z0pCb3J3dGovbnBBdkJnS3BWc0RzQ3lTdmwyOGNyY0JxSUVQMjVaZnRWbUVQ?= =?utf-8?B?SDJEOHRxUnFkc29Yb09pK1lvYlpnTlhmajhUZkFsSUdiU2tUKzlCQ1dUV01i?= =?utf-8?B?NXNldUpDNS8vaTBhdzhva0NBRmQ4cEszOEZpMm9qVk16dURTYU51eXN4d2ZT?= =?utf-8?B?ZGZUdktnWnppVGdrbkNmYmVpS0JGdEk4NWlEdlphbWJGenpxVi9JNldrUGtW?= =?utf-8?B?RitGYkNwMjRPOTBSdStlSHAzKzZsdGhLU1duZ3BNVi8yNDYrNURnZUJMeERh?= =?utf-8?B?MlI0Y25ldE90REJDbTU1eUd5dU5SQlVKUFpTUURnTWkzbHVUeFBMNFhXUExX?= =?utf-8?B?WDR0VTg5MDhCMlJYZk56ME1mL2Q0dTByYUo0QUJNbUN2aHV3akR1SVVpdUNu?= =?utf-8?B?WFVMa0wxTm05cEE1bG82bTY2K3h0MkovOFlka01pNkM3Tm1FVGR5YUZlNDZm?= =?utf-8?B?YTRPayt5S3NpK3loSEVMbzNoUVFuT3d6dHY2OWoxZENHQ2REOGNkdVh2K2hG?= =?utf-8?B?SXVVMWh4cHdrQXZHMHYxVjc4amtiZXltVFBVWXZGcGZ2eHk0Y3hadkFrbThK?= =?utf-8?B?RVVjOWZ5d1B1cTlIRE5VdHovREQwRGdOMndKTGpuUUtyR1J5ekV3MWpVUDhs?= =?utf-8?B?RjZweUdjTzRnVVAwODdoQVJCR045NWxyN0NTS1VidzhhSXUrMzU1azNhRGpZ?= =?utf-8?B?VzU0MThRVkNyWlV6V29JRmVtMVk3MDMwUytTbWRkdDhibWp2a2FCOWlWSysz?= =?utf-8?B?OHVLd1hsOU53cnJqSFZodENyaWJoOUlTeml6N1IrMEN3QzZLVVRENzl1ZklW?= =?utf-8?B?YWsxMXZnbGEzaTZmcHZTN3ZieVZVc3RhZjdMVE1JOGJYSEk5eFBScUx3RXI5?= =?utf-8?B?OWRZOFRwQzVJYUFCQ2RVRHJxVEszeElwVXVaOU5pcXdpWGdVdkd0NUp3LytD?= =?utf-8?B?RGxhMzNJMWhnK1pGcjFjYVljb1UwMVB5UGxLeGpBZFVlYlJZZnN0djFVNlJj?= =?utf-8?B?ZTZJY0FlRnRKenM3bjZuemFKM0M3UVZPMlVqeWFtUFdDZkw3MW01Nys1S1p0?= =?utf-8?Q?m0xyDqjQTcfveeJefmZiYHI=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: d45b8692-cf92-4b81-3e45-08d9b0263d6e X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2021 15:14:13.8264 (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: 9OqpCiZyX6+HnoJvtVJFn84yaImPJ5MWcw9LQjtwEfPfQTqRZHGut7iDKOVHg6EO960xznAf/FIZMnl8HRzMQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5095 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 On 11/25/2021 1:56 PM, Slava Ovsiienko wrote: >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Thursday, November 25, 2021 13:54 >> To: Andrew Rybchenko ; Ajit Khaparde >> ; Somnath Kotur >> ; Rahul Lakkireddy >> ; Slava Ovsiienko >> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ; >> dev@dpdk.org >> Subject: Re: [PATCH v3] ethdev: deprecate header fields and metadata flow >> actions >> >> On 11/24/2021 3:37 PM, Viacheslav Ovsiienko wrote: >>> The generic RTE_FLOW_ACTION_TYPE_MODIFY_FIELD action was >> introduced by >>> [1]. This action provides an unified way to perform various arithmetic >>> and transfer operations over packet network header fields and packet >>> metadata. >>> >>> [1] commit 641dbe4fb053 ("net/mlx5: support modify field flow action") >>> >>> On other side there are a bunch of multiple legacy actions, that can >>> be superseded by the generic modify field action: > [.. snip ..] >>> >>> The VLAN set actions are interrelated to VLAN header insertion/removal >>> and supported by multiple PMDs and supposed to be just deprecated but >>> not be removed in 22.11. >>> >> >> Why not remove them for v22.11? Do you think PMDs can't change the >> existing implementation until 22.11? > > Yes, this is a main concern - these actions are supported by multiple PMDs, > and its handling might be a little bit complicated. For example, in mlx5 > SET_VLAN_ID can be translated into different HW/FW primitives > depending on presence of PUSH_VLAN action. I think any PMD should do > the check of VLAN actions order for the case of PUSH, replacing with > MODIFY_FIELD would sophisticate the check > > In mlx5 we are going to support MODIFY_FIELD and kept SET_VLAN_XX > in any combinations, but, actually, there is no objection about dropping > SET_VLAN_XXX regarding mlx5. I just would not like to force > the commitments for that from other PMDs. > >>> Signed-off-by: Viacheslav Ovsiienko >>> >>> -- >>> v2 - deprecation.rst is updated >>> v3 - doc comments addressed >>> - commit message comments addressed >>> - SET_VLAN_VID and SET_VLAN_PCP actions deprecated, but will not >>> be removed in 22.11 >> >> Deprecated symbols are to prevent new code using them, but for this case >> there is no alternative, since PMDs still don't support >> 'RTE_FLOW_ACTION_TYPE_MODIFY_FIELD' yet. >> This patch is forcing users to use deprecated actions (except from mlx). >> >> What about a slight change: >> 1- In this release, update header/document as >> 'RTE_FLOW_ACTION_TYPE_MODIFY_FIELD' >> is preferred way if supported. Instead of deprecating old ones. >> >> 2- Have an agreement with PMD maintainers to switch to new action before >> v22.11, >> and don't accept old action implementation in PMDs anymore. >> Based on agreement update 'deprecation.rst' in this release to note that >> old actions will be removed on v22.11. >> (It would be good to have a check to prevent old actions merged during that >> time.) >> >> 3- In v22.11, remove old actions, the PMDs that don't support MODIFY_FIELD >> action will lose the feature. >> >> What do you think? > > In my opinion, deprecation warns about coming changes - entity is going to be > removed or changed. It does not force to take some immediate action now, > just to be aware about. > > There are two questions: > - do we want to replace a bunch of legacy actions with new one? I suppose - yes, there > is a lot of advantages > - are we going to do this with MODIFY_FIELD? Yes, this is an intention. > > So, we have answers for these questions now, and should handle legacy actions accordingly - > mark as deprecated and provide the clue about MODIFY_FIELD. > > The question remaining - how we are going to proceed. Actions can't be removed till > alternative is provided. So, in my understanding the process should be: > > A. mark actions as deprecated, to advertise an intention > B. implement MODIFY_FIELD support (maintainers agreement/commitment), assign the due date for this > C. advertise the date of legacy actions removal (if it was not claimed in B) > D. remove legacy actions entirely > > We are doing step A now. > Also step B is imposed by advertising the removal date. It is ultimate approach, and is not exactly what we need. > Do we have alternative softened way to encourage PMDs to be updated? No objections to follow 😊. > We are aligned on the intention. For (A), those symbols interface with both drivers and applications, for drivers no concern on deprecating the symbols but I think it is wrong to deprecate from applications perspective. Slightly updated version: A. document legacy actions as not preferred way, but applications still can use them, and no change is required by applications (unless they prefer to use new action). For PMDs we don't allow any more implementation of these actions. B. PMDs implement 'MODIFY_FIELD', have a deadline for it (same with your B.) Assuming deadline is v22.11, announce that old actions will be deprecated on v22.11 in this release. C. on v22.11 deprecate old actions, exiting applications still can use them but new code should use 'MODIFY_FIELD' action. Announce removal date for the legacy actions D. Remove legacy actions entirely Down side is, from this release to until legacy actions are removed, PMD needs to maintain both legacy and 'MODIFY_FIELD' actions. But hopefully can provide smooth transitions for the applications. What do you think? btw, this for the legacy actions that is implemented at least by one PMD, we can remove the ones that are not implemented. > Summary: > - If we are OK about intention - step A should be taken, we should emit deprecation > - we need to gain "B". Now it is proposed to do with advertising the removal date. Alternatives? > > With best regards, > Slava >