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 C4EF6424B8; Mon, 30 Jan 2023 03:34:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6583B40EDD; Mon, 30 Jan 2023 03:34:14 +0100 (CET) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2063.outbound.protection.outlook.com [40.107.94.63]) by mails.dpdk.org (Postfix) with ESMTP id BBF5740A8A for ; Mon, 30 Jan 2023 03:34:12 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y2PxZA6K3HvfAdVWOXKZPUZwB/IWfUZUG33CNDkrp6drOPvKXeCOfRZ8xTQeYGqUjuDOGovpwgjHlXwpb+lk5/Ivhevc9s4I1UKCvd11zndtFSU2WSTgFfN29jt4EmFl2tUK3VLjBjbZ3k8Hdl+rMZAPfsTgGzewjIydJPGVAbcTOq+2brybMQK0pU3LpFfXBmnIM+XRNDjneNmcDvDbW8Xk/utiQC5QYgQEhA5mpewXeLu+nwINoupy912/n+MtRKPlfpRquR+rWgqZ1g8ogxEnX/ZVnJJOdlRpDSAnJNZs61CG12AB+/qscTnpN1nxlttkSpXh05MUu6b4qGZ1gw== 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=D5fhVaO3Y/IXYGRxOSM6LSoaTyEYauEtWZn1zaS1MNI=; b=kYLjumCxh1y8Nwx57P/R04Rf5/NsmA8Lt1AdNeZq+UlQXkTlr50jXzWb/KDonPni4gF0Y3cut/LCc53gokqjiol5Vj3gXjkeQXIPSu1z2EJ6Ja/btpjrKvtwAL7gXYJFOXCrpD4rvXADpd0HA6gX+6xvOJ56YEP1v4fIEgT2HLlvNWAUENtjWD7AlisrUuoGhi2WvlZaxeQoMx7a/6nCkfFLyS8YfRWod32gBKbWxyDnU0IlfkE3aRw9QDLeF0L2iG9f4PJQtWOfwA5mXvdL2k8QirxkxKurNTDxRtV6NcxtOhppKQrMfbQTd6t5bZt3GgKPITPqDVcSmmkPvmeRvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D5fhVaO3Y/IXYGRxOSM6LSoaTyEYauEtWZn1zaS1MNI=; b=ig3993R09mthWzzr6ls8JfMWDsT5t+LBr+3ubvuU1U0cEXjIG1V7UA7GHZJsbYjqEoAv7f6/vVR1s/kdHek5yCKU/KoF+n1jsSX2zxz1nt3YNBgZbo4x+Q5Iiqt581rjiJiQtOaP0nXtKZhXK9Mlvft5LFf9soprFNUIKJJ15W0hhzmawlMZ6D3QzXHdsvdbSo0102n1uSDkwQG+VQLtr0ZPBwE5mJeQiBHvjfNC5hQVLK7hEi2sa0nWVuBl2QwdwZoo65V15c9T2wKmRXQQk+d9Awye3Jx3SW8TuvE0s+f01uRajaoFftwUcj3e9p76LpBFOX38WQoHRtar8A8WmA== Received: from CH0PR12MB5266.namprd12.prod.outlook.com (2603:10b6:610:d1::10) by CH0PR12MB5108.namprd12.prod.outlook.com (2603:10b6:610:bf::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.36; Mon, 30 Jan 2023 02:34:08 +0000 Received: from CH0PR12MB5266.namprd12.prod.outlook.com ([fe80::6a7f:5a07:29a:e81e]) by CH0PR12MB5266.namprd12.prod.outlook.com ([fe80::6a7f:5a07:29a:e81e%4]) with mapi id 15.20.6043.036; Mon, 30 Jan 2023 02:34:08 +0000 From: Rongwei Liu To: Ivan Malov CC: Matan Azrad , Slava Ovsiienko , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Aman Singh , Yuying Zhang , Ferruh Yigit , Andrew Rybchenko , "dev@dpdk.org" , Raslan Darawsheh Subject: RE: [PATCH v7] ethdev: add special flags when creating async transfer table Thread-Topic: [PATCH v7] ethdev: add special flags when creating async transfer table Thread-Index: AQHY+CCrvOGvyt+zc0SCwGdhWlPLPa62i3OAgAAbNdA= Date: Mon, 30 Jan 2023 02:34:08 +0000 Message-ID: References: <20221114115946.1074787-1-rongweil@nvidia.com> <2cd321-40eb-799f-abe-d0258f92e6de@arknetworks.am> In-Reply-To: <2cd321-40eb-799f-abe-d0258f92e6de@arknetworks.am> Accept-Language: zh-CN, 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=nvidia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH0PR12MB5266:EE_|CH0PR12MB5108:EE_ x-ms-office365-filtering-correlation-id: 140cec27-5821-45c0-5386-08db026a7686 x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /LqFmMZDXJF4rChnz2WgSYE8zNl73/xHJrhYJDV9ln+V3+9aeq1XC475O6MvZIjncZS8K0+ZktjX5s52Jhk+frBCTcECA7C6a6PKjwgfUjJ3vysE7MzbKWhD6vALZ6zImpIWgI3JYQIaNr0BNCrvdhb7UlHWCLu9GT4xY1s4j8SmbkbjDr2wuWsbnYzQJT7RaI1pLJDZPG7Cumki/eORFr6I16UHDMGkNO6MG+oh05o69U4N9OGBWWy/z7cS8KCeyCJXQ6usefTz9eTcBtCpkNwxVfiKkLjG3lwkBGGCJbs6K2mx2Ym/RvZG+dyeupIIbWaDhuRxPV93+rXGMVKE0AhceF3xIlhWVxBc+cGM0/meAgID+DaRazLHcwPUp0xvGAvnwpuDxD8QSMLf5PqcnysOSoBrvfW6quxTuWz6rtkIJRWc1qV9ru9FYLp7G9c11oIyEkwkteRB7V1X82/4l5glyXfK+9JsY2ave9hS9YZhB0Fy5kD+WbyZsby/KF3Vcy5FdVHiQ0geIFxZJzqjH3/fO3FxhJWDjkTuy0WczvqZaPiQPZqVroUKzCPGYydHcCE+Q67QwU2lVByu3Aw4KcUpVV9xmcQH5WjirqMX7dqTw53Ie8wpfeJOSheHxDaAS1vhT6djsodsRLBM8XZU8lgTkrp4pagtitVay4Hv6Fg21bzBGYsN7vOuuVaUC7WVuQFeVyhUyZ1lPQzmBpFjrA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR12MB5266.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(39860400002)(136003)(366004)(346002)(376002)(396003)(451199018)(2906002)(52536014)(5660300002)(38070700005)(86362001)(83380400001)(8936002)(30864003)(41300700001)(71200400001)(478600001)(26005)(9686003)(53546011)(7696005)(6506007)(186003)(66899018)(107886003)(55016003)(33656002)(66556008)(66946007)(38100700002)(66476007)(6916009)(66446008)(64756008)(76116006)(4326008)(8676002)(54906003)(122000001)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LKgMgAZL+Epq/jnCl/Njiu2lBMRvW/k9fPsQIQu1kiiFfySAUbtmenDKe0r2?= =?us-ascii?Q?veKypu5aXAspKHk/AHW9cbjowWuIrG2rLqVNMWq9nK8nXrg+hC9CwdHNdlkH?= =?us-ascii?Q?ZEBuiBPuKXRWwWOgLvvKDzOg+fdyJvSwqK/Ubc+jomti53ucLZvd/gKjozl8?= =?us-ascii?Q?EaXjjdjzuFYl1oR5QlXUR2rzQxshBH2l29bqD/s5dZVQFe963wXcPth0ATQ5?= =?us-ascii?Q?l/SjzFffOWOSOb6Hq72YF2Hj6NDZEsDQC0FiEvVAZsH1tL8AD4VTAhyUKZKj?= =?us-ascii?Q?7HzydPn7jd9/WTuxejlxGaGgAk3EemHTyvMEEQObV003VQJ4pkKzxetlb0Po?= =?us-ascii?Q?GBw90xilnt8aM4YdZg2B75PAye2vE6G4G6WPvBTfsTh5rHBPdg9mUBdrN8YZ?= =?us-ascii?Q?IhfdQBvAyS75l3mk2ffDHyA4nBe/R0IvmEomuOYGBlBlQr2wu4k35UAfa/jy?= =?us-ascii?Q?mv5lEWcnsfsKfA2a3BjQp4LRdFJf+9q9rSMvafZYPq1SQLnjTWo88efUmziy?= =?us-ascii?Q?471jVKf8BBL8I+IdjomiS3bXsS/pnluniJp4VqnXii8sbYgdKzOq5c9HGGd0?= =?us-ascii?Q?V8fjTr+gkoVtmk4xw9bGzKqh8c9KgmqwbJvtRON+Kc3h87sqWzUa2Z7pcnXz?= =?us-ascii?Q?t1fwHiWhBDemZiF5kGIvbjN98Aw8wgFCacPIcpUUsgNscNgQl/L3X1wt+PVX?= =?us-ascii?Q?O2LQddCz5uMV0f8Qk5ChZkTqYA+axgSUMWgxqNp2LxfExIJJNNqVT/ceDOb+?= =?us-ascii?Q?y3xUnmM8MZi13vOZhZQCVjLwiTr1bJcul0ApAQWvNqs6EhlY7Nb0xK3Yk3OO?= =?us-ascii?Q?Bi4YesjcWyUCqP6W7w9U2zxoWNPk7z13VYoULxu5nv/clmWwaQx3wUpVa8+h?= =?us-ascii?Q?9+prnI1JSzk4H4LwQIcFiN6eJ0RdcVHkndrNucO5WiOjRgtOWK8v6NG5p0og?= =?us-ascii?Q?OWTbIL1ulJsIfhQ/tvng6vVeRlXKcwbb1Q0oRinHjJBgHlDwegc+SMHYcbxu?= =?us-ascii?Q?YQ5OI6hP1DkdKE4ifTWORDI05Klcu1PjYQjxS5zjkI9Yq1SFj2CxXlq+RbCI?= =?us-ascii?Q?G60EgwhZWgxZqjZTVmBeHnZa7rlKSr2zTFAXssIGsCsDq7YYhlSKNdNi0/Pn?= =?us-ascii?Q?QJak60uY1T0kaqBjnQbDkyqt76P4XiRgMIcuOii2exYFX5+qvLvaGXqtGDEM?= =?us-ascii?Q?SKwpCZVbB2/v4PQPMTlJiCV41Iyo6JxLEl9jZFNwI2VDqakFa3oxlVqFzpGu?= =?us-ascii?Q?r6lpsNsc805u0spp6izx+0PWNQ+Ojwwuu58r83bOh2r4ni9vlJyVNHQjC0GS?= =?us-ascii?Q?HXKjXQTc8FCL/0JoUF6QuLLUOMi+24ikhpzDV0lCojnJG8+1JQSH6QsK7xvj?= =?us-ascii?Q?vwYFl+0BPxtn1QM9OLyC5GP+oQutL1GuDOZ6LJcIbWrUZ2hnBPt4D/TLY4Qd?= =?us-ascii?Q?XI1FsAS7YRpzGMG99j7ibB6JRcGO6j+caqUS0iJzeVOxYAAKbF3Xv17HwC7w?= =?us-ascii?Q?cThAIxsDpcvluim7xEsziqwvdzL1K6Tm4IA+ZnNBpdDsyX67MAI6Fv2Gpj4l?= =?us-ascii?Q?3Pmw59I0/KExrUtXW/cqWqjkEkyTrFCKp5RedXF0?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH0PR12MB5266.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 140cec27-5821-45c0-5386-08db026a7686 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2023 02:34:08.0891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 95x8eQPO6D9NqMk+T3elc99s0hiy1lfaN3CxT76oJpB8vz6Mn+mJLXBR2lJkITCUiEc7kCNb4jj0LKqy+f6dZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR12MB5108 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 Ivan, BR Rongwei > -----Original Message----- > From: Ivan Malov > Sent: Monday, January 30, 2023 08:00 > To: Rongwei Liu > Cc: Matan Azrad ; Slava Ovsiienko > ; Ori Kam ; NBU-Contact- > Thomas Monjalon (EXTERNAL) ; Aman Singh > ; Yuying Zhang ; > Ferruh Yigit ; Andrew Rybchenko > ; dev@dpdk.org; Raslan Darawsheh > > Subject: Re: [PATCH v7] ethdev: add special flags when creating async tra= nsfer > table >=20 > External email: Use caution opening links or attachments >=20 >=20 > Hi Rongwei, >=20 > Thanks for persevering. I have no strong opinion, but, at least, the fact= that the > new flags are no longer meant for use in rte_flow_attr, which is clearly = not > the right place for such, is an improvement. >=20 Thanks for the suggestion, move it to rte_flow_table_attr now and it' dedic= ated to async API. > However, let's take a closer look at the current patch, shall we? >=20 > But, before we get to that, I'd like to kindly request that you provide a= more > concrete example of how this feature is supposed to be used. Are there so= me > real-life application examples? >=20 Sure. > Also, to me, it's still unclear how an application can obtain the knowled= ge of > this hint in the first instance. For example, can Open vSwitch somehow te= ll > ethdevs representing physical ports from ones representing "vports" (host > endpoints)? > How does it know which attribute to specify? >=20 Hint should be initiated by application and application knows it' traffic p= attern which highly relates to deployment. Let' use VxLAN encap/decap as an example: 1. Traffic from wire should be VxLAN pattern and do the decap, then send to= different vports. flow pattern_template 0 create transfer relaxed no pattern_template_id 4 te= mplate represented_port ethdev_port_id is 0 / eth / ipv4 / udp / vxlan / ta= g index is 0 data is 0x33 / end flow actions_template 0 create transfer actions_template_id 4 template raw_= decap index 0 / represented_port ethdev_port_id 1 / end mask raw_decap inde= x 0 / represented_port ethdev_port_id 1 / end flow template_table 0 create group 1 priority 0 transfer wire_orig table_id= 4 rules_number 128 pattern_template 4 actions_template 4 2. Traffic from vports should be encap with different VxLAN header and send= to wire. flow actions_template 1 create transfer actions_template_id 5 template raw_= encap index 0 / represented_port ethdev_port_id 0 / end mask raw_encap inde= x 0 / represented_port ethdev_port_id 0 / end flow template_table 0 create group 1 priority 0 transfer vport_orig table_i= d 5 rules_number 128 pattern_template 4 actions_template 5 > For the rest of my notes, PSB. >=20 > On Mon, 14 Nov 2022, Rongwei Liu wrote: >=20 > > In case flow rules match only one kind of traffic in a flow table, > > then optimization can be done via allocation of this table. >=20 > This wording might confuse readers. Consider rephrasing it, please: > If multiple flow rules share a common set of match masks, then they might > belong in a flow table which can be pre-allocated. >=20 > > Such optimization is possible only if the application gives a hint > > about its usage of the table during initial configuration. > > > > The transfer domain rules may process traffic from wire or vport, > > which may correspond to two kinds of underlayer resources. >=20 > Why name it a "vport"? Why not "host"? >=20 > host =3D packets generated by any of the host's "vport"s wire =3D packets= arriving > at the NIC from the network Vport is "virtual port" for short and contains "VF/SF" for now.=20 Per my thoughts, it' clearer and maps to DPDK port probing/management. >=20 > > That's why the first two hints introduced in this patch are about wire > > and vport traffic specialization. > > Wire means traffic arrives from the uplink port while vport means > > traffic initiated from VF/SF. >=20 > By the sound of it, the meaning is confined to just VFs/SFs. > What if the user wants to match packets coming from PFs? >=20 It should be "wire_orig". > > > > There are two possible approaches for providing the hints. > > Using IPv4 as an example: > > 1. Use pattern item in both template table and flow rules. > > > > pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end > > async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end > > > > "ANY_VPORT" needs to be present in each flow rule even if it's just > > a hint. No value to match because matching is already done by > > IPv4 item. >=20 > Why no value to match on? How does it prevent rogue tenants from spoofing > network headers? If the application receives a packet on a particular vpo= rt's > representor, then it may strictly specify item represented_port pointing = to that > vport so that only packets from that vport match. >=20 > Why isn't security a consideration? >=20 There is some misunderstanding here. "ANY_VPORT" is the approach (new matc= hing item without value) suggested by you.=20 I was explaining we need to apply it to each flow rule even if it's only a = flag and no value. > > > > 2. Add special flags into table_attr. > > > > template_table 0 create table_id 0 group 1 transfer vport_orig > > > > Approach 1 needs to specify the pattern in each flow rule which wastes > > memory and is not user friendly. >=20 > What if the user has to insert a group of rules which not only have the s= ame > set of match masks but also share exactly the same match spec values for = a > limited subset of network items (for example, those of an encap. header)?= This > way, a subset of network item specs can remain fixed across many rules. D= oes > that count as wasting memory? >=20 Per my understanding, you are talking "multiple spec and mask mixing". =20 We provide a hint in this patch and no assumption on the matching patterns. I think matching pattern is totally controlled by application layer. "wasting memory " because your approach needs to scatter in each rule while= this patch only needs to set table_attr once. No relation with matching patter totally. > If yes, then the problem does not concern just a single pair of attribute= s, but > rather deserves a more versatile solution like some sort of indirect grou= ping of > constant item specs. > Have you considered such options? See above. >=20 > > This patch takes the 2nd approach and introduces one new member > > "specialize" into rte_flow_table_attr to indicate possible flow table > > optimization. >=20 > The name "specialize" might have some drawbacks: > - spelling difference (specialise/specialize) > - in grep output, will mix with flows' "spec" > - quite long > - not a noun >=20 > Why not "scope"? Or something like that? >=20 It means special optimization to PMD. "scope" is more rogue.=20 > > > > By default, there is no hint, so the behavior of the transfer domain > > doesn't change. > > There is no guarantee that the hint will be used by the PMD. > > > > Signed-off-by: Rongwei Liu > > Acked-by: Ori Kam > > > > v2: Move the new field to template table attribute. > > v4: Mark it as optional and clear the concept. > > v5: Change specialize type to uint32_t. > > v6: Change the flags to macros and re-construct the commit log. > > v7: Fix build failure. > > --- > > app/test-pmd/cmdline_flow.c | 26 +++++++++++++++++++ > > doc/guides/prog_guide/rte_flow.rst | 15 +++++++++++ > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++- > > lib/ethdev/rte_flow.h | 28 +++++++++++++++++++++ > > 4 files changed, 71 insertions(+), 1 deletion(-) > > > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c > > index 88108498e0..62197f2618 100644 > > --- a/app/test-pmd/cmdline_flow.c > > +++ b/app/test-pmd/cmdline_flow.c > > @@ -184,6 +184,8 @@ enum index { > > TABLE_INGRESS, > > TABLE_EGRESS, > > TABLE_TRANSFER, > > + TABLE_TRANSFER_WIRE_ORIG, > > + TABLE_TRANSFER_VPORT_ORIG, > > TABLE_RULES_NUMBER, > > TABLE_PATTERN_TEMPLATE, > > TABLE_ACTIONS_TEMPLATE, > > @@ -1158,6 +1160,8 @@ static const enum index next_table_attr[] =3D { > > TABLE_INGRESS, > > TABLE_EGRESS, > > TABLE_TRANSFER, > > + TABLE_TRANSFER_WIRE_ORIG, > > + TABLE_TRANSFER_VPORT_ORIG, > > TABLE_RULES_NUMBER, > > TABLE_PATTERN_TEMPLATE, > > TABLE_ACTIONS_TEMPLATE, > > @@ -2933,6 +2937,18 @@ static const struct token token_list[] =3D { > > .next =3D NEXT(next_table_attr), > > .call =3D parse_table, > > }, > > + [TABLE_TRANSFER_WIRE_ORIG] =3D { > > + .name =3D "wire_orig", > > + .help =3D "affect rule direction to transfer", > > + .next =3D NEXT(next_table_attr), > > + .call =3D parse_table, > > + }, > > + [TABLE_TRANSFER_VPORT_ORIG] =3D { > > + .name =3D "vport_orig", > > + .help =3D "affect rule direction to transfer", > > + .next =3D NEXT(next_table_attr), > > + .call =3D parse_table, > > + }, > > [TABLE_RULES_NUMBER] =3D { > > .name =3D "rules_number", > > .help =3D "number of rules in table", @@ -8993,6 +9009,16 > > @@ parse_table(struct context *ctx, const struct token *token, > > case TABLE_TRANSFER: > > out->args.table.attr.flow_attr.transfer =3D 1; > > return len; > > + case TABLE_TRANSFER_WIRE_ORIG: > > + if (!out->args.table.attr.flow_attr.transfer) > > + return -1; > > + out->args.table.attr.specialize =3D > > RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG; > > + return len; > > + case TABLE_TRANSFER_VPORT_ORIG: > > + if (!out->args.table.attr.flow_attr.transfer) > > + return -1; > > + out->args.table.attr.specialize =3D > > RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG; > > + return len; > > default: > > return -1; > > } > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > index 3e6242803d..d9ca041ae4 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -3605,6 +3605,21 @@ and pattern and actions templates are created. > > &actions_templates, nb_actions_templ, > > &error); > > > > +Table Attribute: Specialize > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Application can help optimizing underlayer resources and insertion > > +rate by specializing template table. > > +Specialization is done by providing hints in the template table > > +attribute ``specialize``. > > + > > +This attribute is not mandatory for each PMD to implement. > > +If a hint is not supported, it will be silently ignored, and no > > +special optimization is done. >=20 > Silently ignoring the field does not sit well with the application's poss= ible intent > to drop represented_port match from the patterns. From my point of view, = if > the application sets this attribute, it believes it can rely on it, that = is, packets > coming from host won't match if the attribute asks to match network only,= for > instance. Has this been considered? >=20 > > + > > +If a table is specialized, the application should make sure the rules > > +comply with the table attribute. >=20 > How does the application enforce that? I would appreciate you explain it. >=20 > > + > > Asynchronous operations > > ----------------------- > > > > diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > index 96c5ae0fe4..b3238415f4 100644 > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > @@ -3145,7 +3145,8 @@ It is bound to > ``rte_flow_template_table_create()``:: > > > > flow template_table {port_id} create > > [table_id {id}] [group {group_id}] > > - [priority {level}] [ingress] [egress] [transfer] > > + [priority {level}] [ingress] [egress] > > + [transfer [vport_orig] [wire_orig]] > > rules_number {number} > > pattern_template {pattern_template_id} > > actions_template {actions_template_id} diff --git > > a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index > > 8858b56428..c27b48c5c1 100644 > > --- a/lib/ethdev/rte_flow.h > > +++ b/lib/ethdev/rte_flow.h > > @@ -5186,6 +5186,29 @@ rte_flow_actions_template_destroy(uint16_t > > port_id, */ struct rte_flow_template_table; > > > > +/**@{@name Special optional flags for template table attribute > > + * Each bit is a hint for table specialization, > > + * offering a potential optimization at PMD layer. > > + * PMD can ignore the unsupported bits silently. > > + */ > > +/** > > + * Specialize table for transfer flows which come only from wire. > > + * It allows PMD not to allocate resources for non-wire originated tra= ffic. > > + * This bit is not a matching criteria, just an optimization hint. >=20 > You intended to spell "criterion", I take it. And still, it *is* a match = criterion. > I'm not denying the possible need to have this criterion at the earliest > processing stage. That might be OK, but I still have a hunch that this is= too > specific. > Please see my comment above about wasting memory. > I guess this type of criterion is not the only one that may need to be pr= ovided > as a "hint". >=20 > > + * Flow rules which match non-wire originated traffic will be missed > > + * if the hint is supported. >=20 > And what if it's unsupported? Is it indeed OK to silently ignore it? >=20 > > + */ > > +#define RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_WIRE_ORIG > RTE_BIT32(0) >=20 > Why not RTE_FLOW_TABLE_SCOPE_FROM_WIRE ? >=20 > To me, TRANSFER looks redundant as this bit is already supposed to be tic= ked > in the "struct rte_flow_attr flow_attr" field of the "struct > rte_flow_template_table_attr". >=20 > > +/** > > + * Specialize table for transfer flows which come only from vport > > +(e.g. VF, > > SF). >=20 > And PF? >=20 > > + * It allows PMD not to allocate resources for non-vport originated tr= affic. > > + * This bit is not a matching criteria, just an optimization hint. > > + * Flow rules which match non-vport originated traffic will be missed > > + * if the hint is supported. > > + */ > > +#define RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG > RTE_BIT32(1) >=20 > Why not RTE_FLOW_TABLE_SCOPE_FROM_HOST ? >=20 > > +/**@}*/ > > + > > /** > > * @warning > > * @b EXPERIMENTAL: this API may change without prior notice. > > @@ -5201,6 +5224,11 @@ struct rte_flow_template_table_attr { > > * Maximum number of flow rules that this table holds. > > */ > > uint32_t nb_flows; > > + /** > > + * Optional hint flags for PMD optimization. > > + * Value is composed with RTE_FLOW_TABLE_SPECIALIZE_*. > > + */ > > + uint32_t specialize; >=20 > Why not "scope" or something? >=20 > > }; > > > > /** > > -- > > 2.27.0 > > >=20 > Thank you.