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 6768FA0C45;
Thu, 25 Nov 2021 15:15:55 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id E9BD9426FB;
Thu, 25 Nov 2021 15:15:54 +0100 (CET)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
by mails.dpdk.org (Postfix) with ESMTP id 840FA40DFD
for <dev@dpdk.org>; Thu, 25 Nov 2021 15:15:53 +0100 (CET)
X-IronPort-AV: E=McAfee;i="6200,9189,10178"; a="235763606"
X-IronPort-AV: E=Sophos;i="5.87,263,1631602800"; d="scan'208";a="235763606"
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
25 Nov 2021 06:15:52 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.87,263,1631602800"; d="scan'208";a="598167155"
Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18])
by fmsmga002.fm.intel.com with ESMTP; 25 Nov 2021 06:15:50 -0800
Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by
ORSMSX605.amr.corp.intel.com (10.22.229.18) 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 06:15:46 -0800
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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 06:15:46 -0800
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.100)
by edgegateway.intel.com (134.134.137.103) 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 06:15:46 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=hDlyFjoBOaQkXWKPuo+HhK+sutxQ6VCTlF7Z/ycdwEizanJeZ4HFTytxeARP5Liiw4NxbjaVj5jgJ5G0INWB7F5zre4tK2nJ4nWC7WYxTqevNdfFVmxiZItJuCIhge63Jh51WYblGE8qbwp7Qi3iQ1MOyU46wHhuhxB9q4sV8igFikcVGqYA6sWyEuZge/tlCxWRqWKMvnc7WIjB9FOi3HLYZ0PYgSV0hernSTtronsviQJXmMxNGIh+NIufu8e4MugIG76jZGtARNiD+RT0gPqHBwfboqcdYY7Jgf2A8shVk3S87j/DybXQo7IuyXz37AJHJguYsVD54YwNdnrXpw==
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=VStQ9EPJKsCrkx+CUNnbC+W/G7jkj0Bli2+q6y66n3Y=;
b=SKG66g+Fvb+yfAEXsxD63cF+nrQgcA0OcGPLHee57sXnDJhNImM274e7VFKIV3OWIj+gb5ptEwUCauWF0hmwJcPL9xQR8bBpGdYVn4XP/jX5wH5dFoqs4nPTAlOo3mCcv3PXv7FZm6wIxJEjDRUAAkVF8CN5sr6bM7dbHxr52PdBa7JJjRzIKbhqlNlLnzr+yymcTPQTaB+Ot1sRzD3CrQ0kodX86UfgRMrvUYpGIMBUCecQ5GmOoLu/dhxkHm21FZuV9DwPOV/3edzRKAcVlLNstfxsJKfAjWEZQCR89qPrSmtRXkx1Tomgj1zY50XvDwaKw2knn7NbGBHaT1P7Ww==
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=VStQ9EPJKsCrkx+CUNnbC+W/G7jkj0Bli2+q6y66n3Y=;
b=mUr+D2PHp2faCuMbvFp+on38fbnknLs4jyRzrKNanwXr9+IYj/H4U/v4h2Jsvb4fwzXmcs/YSQ28kQCalN9hzeZgWhTi3U45dprQotAUmMOwhg6ghSnVveAIPKSUN+my7A4NMYGWZrKacjybS/YcfalnQfntxf8HcrXDONtRmSs=
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 PH0PR11MB4920.namprd11.prod.outlook.com (2603:10b6:510:41::22)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.19; Thu, 25 Nov
2021 14:15:45 +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
14:15:45 +0000
Message-ID: <6c52a264-e384-1ec0-2929-1c962290927d@intel.com>
Date: Thu, 25 Nov 2021 14:15:37 +0000
Content-Language: en-US
To: Thomas Monjalon <thomas@monjalon.net>, Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru>, Ajit Khaparde <ajit.khaparde@broadcom.com>,
Somnath Kotur <somnath.kotur@broadcom.com>, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com>, Viacheslav Ovsiienko <viacheslavo@nvidia.com>
CC: <dev@dpdk.org>, <orika@nvidia.com>, Ray Kinsella <mdr@ashroe.eu>
References: <20211123075940.5521-1-viacheslavo@nvidia.com>
<20211124153756.12198-1-viacheslavo@nvidia.com>
<0e5753c9-85c3-1dc1-69d8-460cb0a7b5a4@intel.com> <1989679.70EXCg8c8L@thomas>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [PATCH v3] ethdev: deprecate header fields and metadata flow
actions
X-User: ferruhy
In-Reply-To: <1989679.70EXCg8c8L@thomas>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: DB9PR01CA0021.eurprd01.prod.exchangelabs.com
(2603:10a6:10:1d8::26) 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
DB9PR01CA0021.eurprd01.prod.exchangelabs.com (2603:10a6:10:1d8::26) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.19 via Frontend
Transport; Thu, 25 Nov 2021 14:15:42 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3f08c0d5-1f3c-4f7c-8492-08d9b01e122a
X-MS-TrafficTypeDiagnostic: PH0PR11MB4920:
X-Microsoft-Antispam-PRVS: <PH0PR11MB4920633B870E88D9B8BC3FBA95629@PH0PR11MB4920.namprd11.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:7219;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 1eEpTZFMgZlV6GstajsjliuKr9yXckIzrgRybHM8VzE4peu0bcCVAsYf2BTs63FoH8HYnBw7ntqD+3OzYqXsYVAy+3MjqFsZCgARaSPbnNJ9wNy+pT8Z+tUQoMTdJz9fecPISeEQBZLdr25bIthPzR/Zli7hMbAo2OQiuFgSRrzx/29aLPiI5zfuuOgykwwH+KX2JP2j8mFYOHiGJvpYvOgP4cXpzO0CHxoc16kFbJv+E4m4sgWTXRQtcmrGn/yR2pxrsiQI5x4JlE7kbEmK+yPbkXpCQu6TIEKKqfU1LBVPsPtozFudOM3SW4JrMaJolzBIktrN9zDMw3dMzk43N9hklsPJ5U+dW0zpPfFc4ZxLbbEyaIFJM9JV1ZGoGSFXhk/dmwHyoBGfKnUZio0tWq6d8eIn8NC+BzUKnXCnShZOHkkzjurck5yLk9mZeWYMo7GWM8hICNw7iDHeclIw4oF2W773XfcjxCrq/ssh9hYGeaGvkor9l6g+o0/JQwVDrKuim4/5K6RSAc0WZlgLyTylX3uMtdAHm2yO8cALZ2ISnmn7Edkgi4GukpClM8tnYDdhyVyALhe8ZB+Zjc6ldGUCXzNUTFwZMv/BBwsLshjJwGZCafrTI2tTz6U9S9EaQ4lNWq4oyVABNj8fMtYszQ==
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)(53546011)(86362001)(8676002)(508600001)(6486002)(31696002)(2616005)(6666004)(4326008)(186003)(110136005)(2906002)(36756003)(38100700002)(44832011)(316002)(31686004)(956004)(5660300002)(66946007)(16576012)(66476007)(66556008)(8936002)(82960400001)(26005)(83380400001);
DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OUNPUkJqdHVFbWdUWlljWTJKSHp1cG9Nek5DTVhpMEErQ3ZzcDRudThzMTZS?=
=?utf-8?B?K3ZlQnhpZGJTeFkxallkTHdUSWNpa3QyNEkxenBCOVJZZFM5YkFpb0VzMVRz?=
=?utf-8?B?UjhoOEtVNnVpd3ZKQ2IwQ2E5aTFZa2pYYjQvbytzWGVDaGt3TVVZWkVhK0Jy?=
=?utf-8?B?QUEwVXA2aEozenE4ZWI1R095NkZCVk5ZczNqd3l4NXVRQloyNms2aU5BbWVD?=
=?utf-8?B?Z0doWm95WklMa003a0ZIcFNaOUxKR0dxWGMxUHFXUzlBcFZuRTdob2FCR0Fr?=
=?utf-8?B?L21OQ2NENStNY1UxM2R0QllwSHZNM28waWtaK2tVdkV0bHArV2FRTTB0WmE5?=
=?utf-8?B?RlBrdDdLbCtPVWF2Y2dpOUdkdGJDcFc5WXluVzdKdlVRayt4NHpZNDdwTFJ5?=
=?utf-8?B?cTZHVzNHNFZKYWlEZlZaOTZ6eGF0dXhWVHhZVTNtZkY1RDVPTDAxd1NrU3dq?=
=?utf-8?B?RlExUittS3dzVUZ1TDRxc21MVit5MkE0aWZrRXduTEo4cEZ5Y3FqbzNxWGs5?=
=?utf-8?B?SHVVTFNPbmJqUS95V1RKMzR2RHVySjFIZmJ0eVB1TnRPYk5xWGNMTkxnS3pl?=
=?utf-8?B?QkVpTHo0WGR2U0JPQmxucTM3MFczM2lDektZWDNMeFluQjhWOVV5UlA2ejkr?=
=?utf-8?B?akd6QmlUM3UxR08zeHE4eVNhKzBEa0d6dWlRVlpkSE43UU9QVWJER2k4UThH?=
=?utf-8?B?b2NHYVRnZDRFaHZMODE0ek51aExHSUMyYXdtNUI4QzlGS09SekRiYjFBeCtP?=
=?utf-8?B?R2diVUpPWlRRR2MyRitHcEdDa1JXQnRoNklObStCV3RrRFM2NERvQjE1aGZl?=
=?utf-8?B?cTcyZ2pwSzFXRXV2MDcxZnkySlJKdmFjOTd5dDQyRHRPNENTbkMvUlh2dUV5?=
=?utf-8?B?QnNLS3JuSDU1L1hObDFWZjBocllRaEFQTVMxUWhOZWhURzRwK1Z5QWdaa0s0?=
=?utf-8?B?NVA5VnBWdm9WSFZ1dVl6Wi8rSEYxV2J6dkFNdzNxaW90WTMwWSt2M2RTamc1?=
=?utf-8?B?b2tVM2xtWUdJN04rTDJsckN6UXh6dDI0U1NMRzlTeDBjejc0Z2hXZmJrM2VI?=
=?utf-8?B?OXZkM2laUG15NTRTM21hWFBaU3hrMkNJTWtuMGxPR21jTU1lR1VlNlZRYS9q?=
=?utf-8?B?dGJNWFI5NzFPa0NPSm5oTkR0alJGTTVSS1pkSGxxcXZhYkFiN3BpLzdpOEpm?=
=?utf-8?B?Nm1xemVaYUtCdXlkUjFHWnhsTHVjdXpDVmJuQktNbnIyUVRrWTlBN3JMVU5G?=
=?utf-8?B?bTBBMWxYN1E2SmRGNE5Bak5kYmZ5U2ozT3diaTIrZSs5cjJPdy9iYks5b3gw?=
=?utf-8?B?WWJMZ2lUVXpGWXQ2L1llK2ZONGE5eU8xSDlQQXIvc1VjbHgzZW5oODU2TDRG?=
=?utf-8?B?UUVhRFFsSWtlTDRWdENkTEgrU25jRE0wS1BJaVNNRGU3T2xSY0wxK082K2FC?=
=?utf-8?B?VFR6Wm9oK0QvTE5DUjlnaUZYMHJJdThHUVVOMlBHTDh1TGJxUkNxY01zdXlq?=
=?utf-8?B?eThNQk5ldVBWNDlkbmVwS3Q4cGpkNmQ5Y1R1ZVVKeEdQeVlsNk5EeXpKYUVW?=
=?utf-8?B?SXN4L3QvdkpGM2FOTUt2aitLZE1jWWxleGx4RVlUdUV0TXR4bHdIZFdQa0FF?=
=?utf-8?B?OU5vZWE2anBTL0F5NktuVkdYdnJzSk9rNFlkQ2xjVFRtdjRjZ0Z2TnJ0WmR0?=
=?utf-8?B?V1NZYW9rdEpFc21UQnZjU0tFbkp2alJUbTRFRW90WlpoMkxsclBFZHhYMEVi?=
=?utf-8?B?TTFjOUtIRjRmbCtrbTFPQUpZdE5Mc0NhaUJyalVwYTdkUWdwZE9WaEdzd3JT?=
=?utf-8?B?ZjNQakZGQ3VkYTYvVkNwMGpra2lmcXBjQ2FXSi9yTldIRmlIeHdGK2s0TSth?=
=?utf-8?B?UHpDN0pyS0VmbTh1QUNJUVdlOFlqajlINUg2aGlOYTBsTjNPU3JiK2JwNzV1?=
=?utf-8?B?Qmk1TUs3bFloNTRGRWcrcXpVSVNDWkV5c2t3NTE3Nkl4MHF5bmdMVnNuNlN5?=
=?utf-8?B?OGl1b0NETmE5NXVMc0U1aWlES2wwYisrMzN1cDNHejc5RXlEVTQ3K3M0bjVu?=
=?utf-8?B?TE8xQ2ZkN0R3ZWFONXJtNkRWamtZME02UURRbC84Zml5Um82SlUvYVhGUmJZ?=
=?utf-8?B?TWdwbUMvZUNIV0h4N2dHdlVpR1F4RzJuSUV3RHVvRHVVdFhZZEg1alhleGxs?=
=?utf-8?Q?NT76WGehtOKGO49Ni6lbWN0=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f08c0d5-1f3c-4f7c-8492-08d9b01e122a
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2021 14:15:45.2020 (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: lFxx4aVS/I/ltnUWrDWENonnZVtRC2OM0UwOuBx+xojxpu7XWg6ZkNwa6FvIq1yXh2S6Up8O7b7YWSwgDxLlMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4920
X-OriginatorOrg: intel.com
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
On 11/25/2021 1:06 PM, Thomas Monjalon wrote:
> 25/11/2021 12:53, Ferruh Yigit:
>> 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:
>>>
>>> RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL sfc
>>> RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT
>>> RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC bnxt, cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_DST bnxt, cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_DST cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_TP_SRC cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_TP_DST cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_DEC_TTL mlx5, sfc
>>> RTE_FLOW_ACTION_TYPE_SET_TTL mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_MAC_SRC cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_MAC_DST cxgbe, mlx5
>>> RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ mlx5
>>> RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ mlx5
>>> RTE_FLOW_ACTION_TYPE_INC_TCP_ACK mlx5
>>> RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP mlx5
>>> RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID bnxt, cnxk, cxgbe, enic,
>>> mlx5, octeontx2, sfc
>>> RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP bnxt, cnxk, cxgbe, enic,
>>> mlx5, octeontx2, sfc
>>> RTE_FLOW_ACTION_TYPE_SET_TAG mlx5
>>> RTE_FLOW_ACTION_TYPE_SET_META mlx5
>>>
>>> This note deprecates the following RTE Flow actions:
>>> 1. As not supported by any of PMDs:
>>>
>>> RTE_FLOW_ACTION_TYPE_OF_SET_MPLS_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_DEC_MPLS_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_SET_NW_TTL
>>> RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_OUT
>>> RTE_FLOW_ACTION_TYPE_OF_COPY_TTL_IN
>>>
>>> 2. As supposed to be replaced by generig field modify action:
>>> RTE_FLOW_ACTION_TYPE_OF_DEC_NW_TTL
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_DST
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_DST
>>> RTE_FLOW_ACTION_TYPE_SET_TP_SRC
>>> RTE_FLOW_ACTION_TYPE_SET_TP_DST
>>> RTE_FLOW_ACTION_TYPE_DEC_TTL
>>> RTE_FLOW_ACTION_TYPE_SET_TTL
>>> RTE_FLOW_ACTION_TYPE_SET_MAC_SRC
>>> RTE_FLOW_ACTION_TYPE_SET_MAC_DST
>>> RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ
>>> RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ
>>> RTE_FLOW_ACTION_TYPE_INC_TCP_ACK
>>> RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK
>>> RTE_FLOW_ACTION_TYPE_SET_IPV4_DSCP
>>> RTE_FLOW_ACTION_TYPE_SET_IPV6_DSCP
>>> RTE_FLOW_ACTION_TYPE_SET_TAG
>>> RTE_FLOW_ACTION_TYPE_SET_META
>>>
>>> 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?
>>
>>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
>>>
>>> --
>>> 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 not preventing new code using old actions,
> there are just comments to point to the new direction.
>
Since the 'deprecated' implementation is done as documentation, it doesn't
practically prevent anything, that is true but
if user applications wants to use 'SET_IPV4_SRC' action, she will be have
to use a *deprecated* action for any driver other than mlx.
I just suggest updating the wording so that it still points the direction,
but also clarifies that 'SET_IPV4_SRC' action is still can be used.
Btw, isn't the 'deprecation.rst' to document the long term direction.
>> This patch is forcing users to use deprecated actions (except from mlx).
>
> I don't get it.
> It is encouraging to use the new generic action,
> which is supported only by mlx5 for now.
>
That is the problem, we are deprecating old method and new generic
action is only supported by single PMD. And we didn't give enough
time to other PMDs for the implementation.
And it is a headache for application that a feature is supported in two
different ways in different PMDs.
For some PMDs applications should use 'SET_IPV4_SRC' action, for other
it should use 'MODIFY_FIELD' action, to have same rule.
Wouldn't be nice to move slowly:
- add 'MODIFY_FIELD' as experimental
- give time to PMDs to implement it while old ones are still default
- deprecate old actions and make 'MODIFY_FIELD' default
- remove old actions
In this case single PMD is implementing an action and we are making it
default immediately.
>
>> 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.
>
> Deprecation is just a comment, clearly showing that it may be removed in future.
> In my opinion, it makes the message simple and clear.
>
What does '@deprecated' exactly mean?
What is the expectation from application for a '@deprecated' symbol, keep using
it with new code?
>
>> 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.)
>
> Not sure I get it.
> You want to remove VLAN actions? I think it is premature.
>
Nothing specific to VLAN here.
Main point is having an agreement with other PMD maintainers on the direction,
since they will need to do some update in their code.
>> 3- In v22.11, remove old actions, the PMDs that don't support MODIFY_FIELD
>> action will lose the feature.
>
> The VLAN actions are probably already used a lot in the field.
> I would consider removing them only if it becomes a burden to maintain.
>
I am not saying anything specific to VLAN.
But for all actions, are you suggesting to keep both 'MODIFY_FIELD' and old
actions support in PMDs?
Since this patch has a deprecation note to remove old actions on v22.11.