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 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 <dev@dpdk.org>; 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 <rongweil@nvidia.com>
To: Ivan Malov <ivan.malov@arknetworks.am>
CC: Matan Azrad <matan@nvidia.com>, Slava Ovsiienko <viacheslavo@nvidia.com>,
Ori Kam <orika@nvidia.com>, "NBU-Contact-Thomas Monjalon (EXTERNAL)"
<thomas@monjalon.net>, Aman Singh <aman.deep.singh@intel.com>, Yuying Zhang
<yuying.zhang@intel.com>, Ferruh Yigit <ferruh.yigit@amd.com>, Andrew
Rybchenko <andrew.rybchenko@oktetlabs.ru>, "dev@dpdk.org" <dev@dpdk.org>,
Raslan Darawsheh <rasland@nvidia.com>
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: <CH0PR12MB5266573B4BF360551993658FABD39@CH0PR12MB5266.namprd12.prod.outlook.com>
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 <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
Hi Ivan,
BR
Rongwei
> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Monday, January 30, 2023 08:00
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Aman Singh
> <aman.deep.singh@intel.com>; Yuying Zhang <yuying.zhang@intel.com>;
> Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> 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 <rongweil at nvidia.com>
> > Acked-by: Ori Kam <orika at nvidia.com>
> >
> > 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.