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 ACDE442F93; Wed, 2 Aug 2023 16:06:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B05540DDB; Wed, 2 Aug 2023 16:06:33 +0200 (CEST) Received: from mgamail.intel.com (unknown [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 25E624021D; Wed, 2 Aug 2023 16:06:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690985190; x=1722521190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mhG1Y4ZKXxSq4+xZ8yTCUsrJrUBXT3ymZtOMaj6nuUw=; b=gcqGpPd+eVg4x9uCBgSsIxLB9LNO/fckg9WPddnVXbASnVfDeb5i5Csr i+X0Txfv921IrJRRgfQWbmj3S1bHKzTdu/zUpbKsjOman0FAsnkcMZKR+ SEutdje575xzyiYYS3JlUE44uwOT6YP/W4BpOpxl8rK/Iv2AyBeHhdzag EBYsC4HugX4rwoPgaz+EVxHYvP3q6CpU6vuWHIPJhKZiGV0MCk+ciZw47 R0lYt68mN+TQSgivvRG8KEyKweDBqyV/434zq/uMyaj/xCFdp9bCdiXFK 6GV9/L6NJc2uvr/ZFwAz07+EIbpfgaXkp5Bm1m/aN17rf3UHPvtEebrlc g==; X-IronPort-AV: E=McAfee;i="6600,9927,10789"; a="433429151" X-IronPort-AV: E=Sophos;i="6.01,249,1684825200"; d="scan'208";a="433429151" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Aug 2023 07:06:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10789"; a="758755883" X-IronPort-AV: E=Sophos;i="6.01,249,1684825200"; d="scan'208";a="758755883" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga008.jf.intel.com with ESMTP; 02 Aug 2023 07:06:28 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 2 Aug 2023 07:06:27 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Wed, 2 Aug 2023 07:06:27 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.102) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Wed, 2 Aug 2023 07:06:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D1t5JLwNX2ZSHHggMRah6LNfKsNwB1zv1+Uz398LzBbDmwes/GuNFy1eQYcuy/eyGZfS3zYVQy3EOomqNX1bWAksGM18kL/ztIThlb+cBAG/SIOMVgzbJv0H0wlB3rntfYsPeM95+A/yqvqnkiZXc/OTQ5wYqONQehqz7j4ODBcIrvbGpuDDpivdf6L4nV5x9m9t2BxhZLqHMHTUfL8t3bpI+/TjmKpLm3QiD31lBpmYzSK+yPZgBtlh8I0bzKzsaTc38RrwY1R+ERUIsEXeDOQbgMXuTNvhGY6E7PhEKYwc0GLAkvYNrZeJZE96Uj5D5KMC99RwFU3otdCAR2QV6A== 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=rOlGyhd3/ZBQ07HJ0SL3Hi2Dbj5gro0SckV/7UU2DA8=; b=b90Q5p7ZcqY6bSXo7frbD0ILdQ1y9McNAhvuVnXjLjgZbe+Mr+AtEfuLBmW5sAKJdZBD3lPBfbTrp2hIDG8Qst8mqM92WGkRW3/H84ulrgJszJZwW9iI5gV9ZT+OAZB5GefB8/BKefQbrLZYfS7rSzBiTMZB33J2wn9Rrqz+7UQ+2eeMphJRd4DFQhFJwCK6zDpEgDT4ZA1YOlax98AHCUrcGQkrqR3GZxqukSNYtkYyNXx0FrdjRdT5PQ4eBcg3x00EqNqoB+O64Bs1fL+ceWp3Npe3yOSMyQjjb1O7karAH3LaBvVp/+erlOOX4cRxxXKVrysGw1krqGuSQy0Bhg== 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 Received: from DS0PR11MB7442.namprd11.prod.outlook.com (2603:10b6:8:14d::22) by DS0PR11MB8163.namprd11.prod.outlook.com (2603:10b6:8:165::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.45; Wed, 2 Aug 2023 14:06:24 +0000 Received: from DS0PR11MB7442.namprd11.prod.outlook.com ([fe80::6550:103e:d4dd:9c39]) by DS0PR11MB7442.namprd11.prod.outlook.com ([fe80::6550:103e:d4dd:9c39%6]) with mapi id 15.20.6631.045; Wed, 2 Aug 2023 14:06:24 +0000 From: "Dumitrescu, Cristian" To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "Zhang, Qi Z" , "thomas@monjalon.net" , "orika@nvidia.com" , "david.marchand@redhat.com" , "Richardson, Bruce" , "jerinj@marvell.com" , "ferruh.yigit@amd.com" CC: "cristian.dumiterscu@intel.com" , "techboard@dpdk.org" , "Mcnamara, John" , "Zhang, Helin" , "dev@dpdk.org" Subject: RE: [PATCH] ethdev: introduce generic flow item and action Thread-Topic: [PATCH] ethdev: introduce generic flow item and action Thread-Index: AQHZxSHaq6JEAAy13km0+kJQgl6M8q/WzPOAgAAjTbA= Date: Wed, 2 Aug 2023 14:06:24 +0000 Message-ID: References: <20230802173451.3151646-1-qi.z.zhang@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D87AB8@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AB8@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS0PR11MB7442:EE_|DS0PR11MB8163:EE_ x-ms-office365-filtering-correlation-id: 918ac97f-874b-4eda-0a90-08db9361a83d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AFj0f4EnGo/q3LFiVpds18qxuGBIuLTI+nrPgLE2s+ySGBhxmS2XFGwotkukzhoIhM6/qvoSKQ4QMEt1K9XuktS3fgEC9bPHZzgYqUMX4J64j6Ejv1x55Yc0jjuRa9Mnyw6fk1gy247094a+VL+zLUh7BTNZySN075z4972JM18RgypQA7ECkzdakebZc5WIxPBpwWLN0pO72MqpawrBAORDUvm2eY9/TV0vhvay+IdXEGa0kntm6orCY3zecUHjH51RXY2IJLlgfAzdAvz7B6jCd5VR38lL9ShP3N6+AOVIteoMYndEHYlhZnMrKUKjrhB2QqJNOAoxNQWrS0fMal9EGQ2TSELXZn4NFpnQy5Z8AU1A2ozcaoxgvwxzx8bu6xNCMise8DMiiDw1DFEbdVl2F7vBBsl5n9eYKX+ON7cgEuuqraUJMyTEFgjmmwLw5lVtiXyIHMC2qc8Jnriro+yQPCI9GJbLo0T4Cm1PCFKoYVvrYuc+FjPPji/Ue7dFaKYY2j+P/jV5kxqa7DO8jQXa4VoJ7FthSl38h8rDa2HuICu0JjzX4gloyocGmGIofe1goey9DiIXYAcAtN7xUZNLg8oK8Oo40/mrkVeLwisSWqgAgaIdTUsCrOgLMb0hkdF/9MCHTGj9XJwYZMpswkyFjiiTbuIjmAxCJ+hDkPM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7442.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(396003)(136003)(366004)(376002)(39860400002)(451199021)(8676002)(5660300002)(66574015)(41300700001)(2906002)(38070700005)(8936002)(83380400001)(52536014)(55016003)(186003)(86362001)(122000001)(478600001)(54906003)(110136005)(316002)(921005)(53546011)(82960400001)(26005)(6506007)(33656002)(64756008)(7696005)(38100700002)(76116006)(66946007)(71200400001)(66446008)(66476007)(66556008)(4326008)(9686003)(41533002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ymHv3W/ywWNL3W+k5TQ6Vz1+uAx01i7NVn5FcOsd7qe//f7KAap5SlhtdG?= =?iso-8859-1?Q?8XJnU11vDYYSacUA1Dfj5jDx5DFrCTsjg7qKi7AzP4xNvqhZ5JT9a1TP0M?= =?iso-8859-1?Q?mI7+Zi/oqvifwnB95PIRyikKc6fMz9LpHWLwcY/2XsIdARRBOE44oC6MG0?= =?iso-8859-1?Q?pdeOSaSsvRQ8mqLMQSrTlBvEe3fAHaI88flFEHA4BI2pq6mZd1a0CNaFyC?= =?iso-8859-1?Q?4kina+3pENbaz2PQCaeHC+6a3GBpqRQ6z6rsR7BFbR9RSktQMoBiWNg5U5?= =?iso-8859-1?Q?g7MzsBApvohRuV/JO50KAadheOClimDh1W54S7uQ8ZzL5mGY3qPd7IAV2K?= =?iso-8859-1?Q?DgFRMum595Dc08+5z8Wr5VKdDhepOSY+MilJRR2faWjUvTiWHFL9tJDAxy?= =?iso-8859-1?Q?HQ8z8xWdV4p9TH1ngfcNa4vmuN8Z0Tie+wNFDhUQbaC3wAGVT7/ZqJRXdm?= =?iso-8859-1?Q?re8cdgujYlzxunwHowCmzQQrsR7T8aZCY1yjyRarXlNDyC9WL9yOgDrNYB?= =?iso-8859-1?Q?cPXiv/q08NJqapDGO0wzSUY55MgiiusntDrsezvb3zEgo3gE6MxUfP2Aps?= =?iso-8859-1?Q?ZVEY0u9CSYWJjRYt7Lijwk6Eeot4LSlzm9yt6Bv55q7qLLvqdI9OZs3rOz?= =?iso-8859-1?Q?+ojg5pLPc7OLWdwszno2s6iX3VIfFVkfXO8L4sxlpdDYXEE8LYxkZZqIyL?= =?iso-8859-1?Q?tK/aHNXxIEbmQ2/S5v2vuaT7ZCijCj1GbMrGUiHsFLtbkjHJTuZXyvz9JD?= =?iso-8859-1?Q?r7R07lvd79JmOIJjCpp6fzaFbAJWGQleh4YYa/rp5bOKfC2Qrhj2B4nliq?= =?iso-8859-1?Q?N3DyJBT8K/kXq6W5903nRHDbIA4rx/wVu4lL+sUhQ2eX1o6r60GcvliW+Q?= =?iso-8859-1?Q?KgpL59s9P4bQ/7nLXhfcefjNwrWPXA+mZhyMZB5GBByxUxHxjaVOfd3it3?= =?iso-8859-1?Q?xFo2Vla3+xbjf2LEhJ884lPrEPQ8CJkd3NEkYiQiHpLWsQ2PXSw4Q9B8sN?= =?iso-8859-1?Q?g8XQ8J0nCY4zjR/t+ScVDEzhd9LkBp2XTvhNJIk7qviCFQwjyxIztxXz7P?= =?iso-8859-1?Q?hSRZYT4KaEBZVp3uwbUQPAPVN7yTSdDzWIzvHLuySMCQoorLMz9A1jJYrV?= =?iso-8859-1?Q?ow4lCptW8aCKwYPmJNbrtuBZUmUQW6+wI9neXEukOTxtNOAjvEWQoustdp?= =?iso-8859-1?Q?bMvY8H3Z95K4fA3RQLR8j6ZqeFcC5PCCvbS6knPueUae2sINtQNY8RAa85?= =?iso-8859-1?Q?Dz/WGVaEpr1ny4O4dQNC9YAut1RiSJnXOe1accBT5EZeEC69pE3zPTVG8Q?= =?iso-8859-1?Q?3cMMD0/VcAeGhvrJZbvLwjzeEy9s/y9hAhBXZm0h/Hz+cJ1o+weK+snO4D?= =?iso-8859-1?Q?73uhaKKUrE3D7VuDUnW6TVdyNMdYE02Ehn7sUtzf147GEBCIszsFwcSJO2?= =?iso-8859-1?Q?mm8fTxyLxWlUQnjkVNB6M21Fr01YqFBMmpyqvmsOS5K31NVHm7qlFzhAiS?= =?iso-8859-1?Q?6OFxVpt3jCO9bz4/zaOeaCdYDGNtN/tCz4/nmGGwz1ceR9GrKJgaSv3Jvf?= =?iso-8859-1?Q?H3Z+tMlAmSTE/L0ZjzLXaUg1qNbMxwyRX2q2nNRVIFt65JkffnpE62rpmM?= =?iso-8859-1?Q?FHT8JeY8/wch7DQlXo9V1jOFqTILG6v3czY36kJT6FUTYBRtB9uXQajg?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7442.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 918ac97f-874b-4eda-0a90-08db9361a83d X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2023 14:06:24.6667 (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: KJj0YM07f6Pmmkp/ajd4lw4csrgVPM0zWp/GH2os4+sF/QWBt69+inZxcHVpje8emKKWENqZ4jJRo3QbcKGHA/91+Qo33DvKGKCW3hcA48Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8163 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 Hi Morten, Thanks for your reply, comments inline below. > -----Original Message----- > From: Morten Br=F8rup > Sent: Wednesday, August 2, 2023 11:25 AM > To: Zhang, Qi Z ; thomas@monjalon.net; > orika@nvidia.com; david.marchand@redhat.com; Richardson, Bruce > ; jerinj@marvell.com; ferruh.yigit@amd.com > Cc: cristian.dumiterscu@intel.com; techboard@dpdk.org; Mcnamara, John > ; Zhang, Helin ; > dev@dpdk.org; Dumitrescu, Cristian > Subject: RE: [PATCH] ethdev: introduce generic flow item and action >=20 > > From: Qi Zhang [mailto:qi.z.zhang@intel.com] > > Sent: Wednesday, 2 August 2023 19.35 > > > > From: Cristian Dumitrescu > > > > For network devices that are programmable through languages such as > > the P4 language, there are no pre-defined flow items and actions. > > > > The format of the protocol header and metadata fields that are used to > > specify the flow items that make up the flow pattern, as well as the > > flow actions, are all defined by the program, with an infinity of > > possible combinations, as opposed to being selected from a finite > > pre-defined list. > > > > It is virtually impossible to pre-define all the flow items and the > > flow actions that programs might ever use, as these are only limited > > by the set of HW resources and the program developer's imagination. > > > > To support the programmable network devices, we are introducing: > > > > * A generic flow item: The flow item is expressed as an array of bytes > > of a given length, whose meaning is defined by the program loaded by > > the network device. >=20 > The flow item is not "generic", it is "opaque": Only the application know= s what this flow item does. This item is definitely not opaque, as it does not contain any pointers/han= dles. It actually contains the exact bytes of the field in clear text, so how is = this opaque? We already have flow items in RTE_FLOW such as RAW, FUZZY, META, TAG, FLEX whose meaning is fully defined by the application, as you state, with some = of them (like FLEX) containing pointers or indices that are completely "opaque". We= could use one of these existing items, but we think it would be cleaner to define= a new one that is more aligned to this specific purpose. The way I would read your comment is that the _format_ of the flow item is defined by the application. But this is how the P4-programmable HW devices = from Intel and other vendors work: the P4 program loaded by the device (i.e. the= data plane application) defines the _format_ of the flow items. >=20 > I hate the concept for two reasons: > 1. The inability for applications to detect which flow items the underlyi= ng > hardware supports. Does RTE_FLOW have any capability to detect what flows are supported by the underlying HW support? How is this a problem introduced by this proposal? > 2. The risk that vendors will use this instead of introducing new flow it= em > types, available for anyone to implement. As stated above, there are already many existing flow items in RTE_FLOW tha= t do just=20 thisc(and even worse, as some of them contain opaque pointers or indices), = such as RAW, FUZZY, META, TAG, FLEX. >=20 > If you proceed anyway, there's a few comments inline below. >=20 > > The device is still expected to accept the > > existing pre-defined flow items such as Ethernet, IPv4/IPv6 headers, > > etc, as long as the program currently loaded on the device is defining > > and using flow items with identical format, but the device is not > > limited to the current set of pre-defined RTE_FLOW flow items. > > > > * A generic flow action: The flow action exact processing is defined > > by the program loaded by the network device, with the user expected to > > know the set of program actions for the purpose of assigning actions > > to flows. The device is still expected to accept the existing > > pre-defined flow actions such as packet drop, packet redirection to > > output queues, packet modifications, etc, as long as the program > > currently loaded on the device is defining and using flow actions that > > perform identical processing, but the device is not limited to the > > current set of pre-defined RTE_FLOW flow actions. > > > > Signed-off-by: Cristian Dumitrescu > > Signed-off-by: Qi Zhang > > --- > > lib/ethdev/rte_flow.h | 82 > +++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 82 insertions(+) > > > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > > index 3fe57140f9..f7889d7dd0 100644 > > --- a/lib/ethdev/rte_flow.h > > +++ b/lib/ethdev/rte_flow.h > > @@ -688,6 +688,15 @@ enum rte_flow_item_type { > > * @see struct rte_flow_item_ib_bth. > > */ > > RTE_FLOW_ITEM_TYPE_IB_BTH, > > + > > + /** > > + * Matches a custom protocol header or metadata field represented > > + * as a byte string of a given length, whose meaning is typically > > + * defined by the data plane program. > > + * > > + * @see struct rte_flow_item_generic. > > + */ > > + RTE_FLOW_ITEM_TYPE_GENERIC, >=20 > Rename: _GENERIC -> _OPAQUE, everywhere. >=20 > > }; > > > > /** > > @@ -2311,6 +2320,32 @@ static const struct rte_flow_item_tx_queue > > rte_flow_item_tx_queue_mask =3D { > > }; > > #endif > > > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this structure may change without prior notice > > + * > > + * RTE_FLOW_ITEM_TYPE_GENERIC > > + * > > + * Matches a custom protocol header or metadata field represented as a > byte > > + * array of a given length, whose meaning is typically defined by the = data > > + * plane program. >=20 > "byte array" -> "opaque data type" This flow item does not contain any pointer or index with hidden meaning, this flow item contains the exact byte array in clear text, so it is not op= aque. The only difference is that you don't have a predefined name for its protoc= ol, as the field format is defined by the P4 program loaded by the HW device. >=20 > > + * > > + * The field length must be non-zero. The field value must be non-NULL= , > with > > the > > + * value bytes specified in network byte order. > > + */ > > +struct rte_flow_item_generic { > > + uint32_t length; /**< Field length. */ > > + const uint8_t *value; /**< Field value. */ >=20 > Suggestion: Change the value type from "const uint8_t *" to "const void *= ". It > makes it easier for the application to use a hierarchy of structures inte= rnally > for this. The "value" should be an array of exactly "length" bytes. Changing the data= type to "void *" is making this field opaque for no good reason IMO. We are simply = following the same pattern used by other flow items such as RAW and FLEX, which are a= lso specified as array of bytes, right? >=20 > > +}; > > + > > +/** Default mask for RTE_FLOW_ITEM_TYPE_GENERIC. */ > > +#ifndef __cplusplus > > +static const struct rte_flow_item_generic rte_flow_item_generic_mask = =3D { > > + .length =3D 0xffffffff, > > + .value =3D NULL, > > +}; > > +#endif > > + > > /** > > * Action types. > > * > > @@ -2989,6 +3024,14 @@ enum rte_flow_action_type { > > * @see struct rte_flow_action_indirect_list > > */ > > RTE_FLOW_ACTION_TYPE_INDIRECT_LIST, > > + > > + /** > > + * Custom action whose processing is typically defined by the data > plane > > + * program. > > + * > > + * @see struct rte_flow_action_generic. > > + */ > > + RTE_FLOW_ACTION_TYPE_GENERIC, > > }; > > > > /** > > @@ -4064,6 +4107,45 @@ struct > rte_flow_indirect_update_flow_meter_mark { > > enum rte_color init_color; > > }; > > > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this structure may change without prior notice. > > + * > > + * Generic action argument configuration parameters. > > + * > > + * The action argument field length must be non-zero. The action argum= ent > > field > > + * value must be non-NULL, with the value bytes specified in network b= yte > > order. > > + * > > + * @see struct rte_flow_action_generic > > + */ > > +struct rte_flow_action_generic_argument { > > + /** Argument field length. */ > > + uint32_t length; > > + /** Argument field value. */ > > + const uint8_t *value; > > +}; > > + > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this structure may change without prior notice. > > + * > > + * RTE_FLOW_ACTION_TYPE_GENERIC > > + * > > + * Generic action configuration parameters. > > + * > > + * Each action can have zero or more arguments. > > + * > > + * @see RTE_FLOW_ACTION_TYPE_GENERIC > > + */ > > +struct rte_flow_action_generic { > > + /** Action ID. */ > > + uint32_t action_id; > > + /** Number of action arguments. */ > > + uint32_t action_args_num; > > + /** Action arguments array. */ > > + const struct rte_flow_action_generic_argument *action_args; > > +}; >=20 > This is a list of arguments, not one argument. You should append "_array" > somewhere in the name, and add a normal (non-list) action, e.g.: >=20 > struct rte_flow_action_opaque { > //Or: "struct rte_flow_action_generic", if you want to keep that name. > /** Action ID. */ > uint32_t action_id; > /** Argument length. */ > uint32_t length; > /** Argument value. */ > const uint8_t *value; > // Or: "const void *value;" for the same reason as for the flow item. > }; >=20 Did you somehow overlooked the "struct rte_flow_action_generic" from just above? An action can have zero, one or more arguments, which are expressed in the "action_args" array; we are requiring the user to provide the action arguments as an array of "struct rte_flow_action_generic" as opposed to a single raw buffer with all the arguments concatenated there, makes sense? >=20 > > + > > /* Mbuf dynamic field offset for metadata. */ > > extern int32_t rte_flow_dynf_metadata_offs; > > > > -- > > 2.31.1 Regards, Cristian