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 2564DA0C47; Wed, 1 Sep 2021 18:28:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EA00D40140; Wed, 1 Sep 2021 18:28:20 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2077.outbound.protection.outlook.com [40.107.220.77]) by mails.dpdk.org (Postfix) with ESMTP id 001C14013F for ; Wed, 1 Sep 2021 18:28:18 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iik7wx/dRfRCWjSptB7+XVfq7VQzYPL1o2zrz0DQDvKIMtl3RndzC38TuPd6nvdJC4jEkArkR3CpToewhTGTRosbjAly7y1ONd6xSH5Qx9mRZsNEN4IlBEJUx7sb0WXilbsTlcLWGdb+HJYZowumCzVVB2IoI2bItKu19D/v4NJ2O3h+a5AxxqtGTXIuMXH0LPS1ZOIRoLLo2GsFv39/X6j7OTXCALFP47svPrmUdjnGUY+zovn26VVsXS/O89wCckMHjlvSytIF26G7o1KN5UeWzUEFzUZEdYCcrexCGhtjs/RpiyBzfZAQCzxqWdv0uRqpnK+UQ50WWKMkWEDWfQ== 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; bh=9j9zbsWizGGQvaCVmYMBptH4xf044Dp1yhevEHkxezk=; b=Ai33aUu7t+c3amqmQQhCCnFls9SPNefxqduQEBn0KOT9SQxwNIrYtA0bIgIR2H8uJm8vzjEPjeSj2QeUbrM9luAW2IGUPqByIblgydexl8ESdU1+7FYlAP/l9KsMnMzgsYiZiLMVj9R8ZjS1AAkfJbVGlUkDXRlfiJXR2KpW+cqI6K+XE4cAgv8OLzWaI6Xftkb/dP5Iilz+037ISpBDv8DzF6Cm3Jj2XGq5GfPhocR41jLRjBf/nWNvU3Grrijoi+wNGOQx4ORXIO+lPtBTVgteoQj8MRlI/IbjcF5bZyIKT5UDjAuf9MJUDsM8OZDLxBn2KmDe79o45yGD/uyJxQ== 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=9j9zbsWizGGQvaCVmYMBptH4xf044Dp1yhevEHkxezk=; b=CCmEuZamzy8CSAtS1tySUJq/UX7A6wxFnJddsldTyEvq4m5vcZx/SCJz8MkvNTfQ2qtPuGc3mtS3fe2i8kalKQDG/zSb3rRQEVNPEdgsg77BXXCCzNksnkKjTnH7eGKjqrRi76CSYLaKZnQxOkpX4RLj9vDg2X625FN3aTYOz8+QFrATg3+s96UG9Rf89DeXLVAQOffqOhn9CnySlo12c6ednz7jvi7BB0vUAsuwAd8oQk8gHEpXRxrkUpsw76lTFREdrz9iepw5yc4nBY9/52TJhCvNlfqHs6sxPZn5mH/DDslaQKP+dkiryB+6BMMi9MeVJzAv7AMMP2e2gpZqlg== Received: from DM8PR12MB5400.namprd12.prod.outlook.com (2603:10b6:8:3b::12) by DM4PR12MB5085.namprd12.prod.outlook.com (2603:10b6:5:388::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19; Wed, 1 Sep 2021 16:28:17 +0000 Received: from DM8PR12MB5400.namprd12.prod.outlook.com ([fe80::d03d:1f75:ca20:6a32]) by DM8PR12MB5400.namprd12.prod.outlook.com ([fe80::d03d:1f75:ca20:6a32%6]) with mapi id 15.20.4457.024; Wed, 1 Sep 2021 16:28:17 +0000 From: Ori Kam To: Andrew Rybchenko , NBU-Contact-Thomas Monjalon , Ferruh Yigit CC: "dev@dpdk.org" , Eli Britstein , Ilya Maximets , Ajit Khaparde , Matan Azrad , Ivan Malov , Viacheslav Galaktionov Thread-Topic: [dpdk-dev] [PATCH] doc: clarify implicit filtering in transfer rules Thread-Index: AQHXn0Og5b6LL0MpBk6v2VJDdTodjKuPVs1w Date: Wed, 1 Sep 2021 16:28:17 +0000 Message-ID: References: <20210901151104.3923889-1-andrew.rybchenko@oktetlabs.ru> In-Reply-To: <20210901151104.3923889-1-andrew.rybchenko@oktetlabs.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oktetlabs.ru; dkim=none (message not signed) header.d=none;oktetlabs.ru; dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 81533153-2661-4c0b-447b-08d96d65813f x-ms-traffictypediagnostic: DM4PR12MB5085: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J/BQ5MMFckmlX/OlbiCGqv9ODJQWDuYaQ/NF/vmr3j9wRDe3SymCeOCw4DWQFw7jQonG8JNbbPviONzly4j2ZsuhBmO48KOmQqp6kPBl8GodOzI2lEBsFsUhgZSKqgnI/LZAYaaCiP7DhOgCcLO7grhG3negtYGFDQ5y24iCeiKUGbcqS3ghkyvi+5YY7bofWV3pgeO48/nrnLIPobm+dd8Ey23uJTkmQO0KQFS1G6+rjZJad5fP4kTlB6/PLE2uMX6V8Av4Z2cFXh8fGngX4n7GDOUx+5DrF4MBW7eMaiPXJnn5eqI5E/p9/ceEMz2SyR+9qjOb3+QuKISwsfJwG6W3MKir23uNfO5azJ1GepQLpNT0DZVlC9ShEQZ3Xt3+OcXNnjvQO0VtnGW4iaXCwOHRuc1xUpm3RXrQCIIrKLOkvgXp3p8bGHIJZbcz8LpfPWs5wlFGNGHluL4kfMWRxkQVtqlhw4BJljle1hO8cbuv7Bfv3bN27fgAW+CAQxAeCqRoD4z+y4YcnOm6lvJj8yZ+++dDmgA1KTB7zzZjZRjsx8guNgPRCGRCmVIN0nlzSNHMmoLZ7U19mPN0lguQr2vEVQJsdBMAkMYXv+N3n695LPWx2S8M326X4rSU2KESUMFJC2kpSXueXmT61F0anMEgDnpH83fJkip4fK1rQ9PnkvzOc+Z5qTEYNTITDBcnDA+X2OBuOi0kJXbk9usg6D/5Jx0SEnF0jUp3Jl+BsAxEN784+oI49GYFkTLbGKLcDeR8I02ZHL5g+y+RDsBMaahNaSzHm6hoO7cRXEjXGjA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR12MB5400.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(39860400002)(396003)(346002)(7696005)(6506007)(76116006)(86362001)(966005)(26005)(186003)(316002)(52536014)(83380400001)(33656002)(66476007)(2906002)(64756008)(66556008)(122000001)(66446008)(4326008)(8936002)(5660300002)(38100700002)(8676002)(9686003)(71200400001)(54906003)(66946007)(478600001)(110136005)(55016002)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?acw4umOyGT9PbSaArQ+Vkj80cKpMEG0VBNuxzjKPgzYd2PMhOZI9+dlLPw5y?= =?us-ascii?Q?+2qxC+XB0D6DhDvPxGIFRU9WCdAqkwIUKypeCu/drYKRsbGslUDxLECrRXRB?= =?us-ascii?Q?fFqTZPMWd6NWu6EAB+GCVMLeRlxlr7u1iOuNGx453erN1PLctF4qEs3Nfo/Y?= =?us-ascii?Q?9n09Imm6J0LGQcVSdSh2k9qN5lJ/J6cIJHF6MIIrGV13dcCyaWA19B9x8lDI?= =?us-ascii?Q?CzqWSyK3hBh1zx0R/OygmpBoKVs8jsPm6asLtQqCyg6qPazTw/6blFJe0/U8?= =?us-ascii?Q?tubebGG8pUIVPTbadCANUNnJvZgA55xb4wlDaU2EXfyaJnmA5WQRopS/7HR2?= =?us-ascii?Q?tfwR+SdD1DDYDSa31gPns/NOmwjpgBp8bUaaLkn8mpl+dGSseHVideZWvCh+?= =?us-ascii?Q?e0PZXTitaTTobHLqqvwvENSTFsc9jdgyzTBz7Jv8T+SwpS7Got+OjYAvY64b?= =?us-ascii?Q?N4iIwDz/Y7V30ZzMuC0D9VaFi7wYkj4PGyeYF2hPpLg+RLlHdsyN/RGAmePM?= =?us-ascii?Q?vBP5kbJOhSpbI3DBey5FbO3XzCAHw2G1Yr52Nt/+sVbDN3UR9hNuKTcCHF+h?= =?us-ascii?Q?Hrwn79Z2lKnptTih6gNmo8PX/RUkGmJtDYOe/5INs+AyXOdPDu4sZsCOOY2v?= =?us-ascii?Q?1rFv6xk8WXt4jPLqvCDqJ7Dr0DfVVfQgE/xY5lrppqZp58j/iJgtXohgxZtD?= =?us-ascii?Q?JoI25F11kFTlp5V5RB4zF9UhThShsVX5RmofHuCUwjNHcYLXxVjsc8pnDKgh?= =?us-ascii?Q?u2n9TTSD0zklkpwarmwLdwfgEpc5xxd7arj0WM6mdY92QX2jnSwMKkjXus3E?= =?us-ascii?Q?NdwOa+FKvOUYlP0g7xYfSJMi3xF2gyP+OzeFvhW0eGHhlfSBL29o0LoKUUVt?= =?us-ascii?Q?B8xCV7R3SZYOghPdNNbFmHi1aRumWqnceT80qdDdnZEFbYhGOs0yQdomMeLD?= =?us-ascii?Q?9Wj84wiokr99T2XUbN0T+FdD9d/i32bcxrSYvYmjjsSQeaIU+GUqA/JKODvo?= =?us-ascii?Q?M6r6tzJJ1xsLq/RZRBYQEWezQmu6Klb+P/xktqlIhbszraHN7qt0jhaSl31o?= =?us-ascii?Q?gml0UgRjNvmR8J92HttDLvWv8i5dP2nZ55s4j8N6WgRuHdUyRwj/LXGLTU6y?= =?us-ascii?Q?vLNamhxJjvVtbHKsethDUg0yF31FF+uEhzHpw9h2+Xru3v0z/0jLsXj4SQM8?= =?us-ascii?Q?4TbUfAbwxObQKmw7HGRKFDyx5vV4weqwkKsTvbRbelfltg+FMHRpuSTT7oiK?= =?us-ascii?Q?mCbX87nPSIvbqpg/mTwQ12DXjmo6R49GdMwkeZS0DrBsdR50ccsxCUIvd5m8?= =?us-ascii?Q?vcGu2NY9Yko5VDT5R7CdTw2S?= 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: DM8PR12MB5400.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81533153-2661-4c0b-447b-08d96d65813f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2021 16:28:17.5464 (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: ZEHYdVXwKjn1NGZEZ4sIyrmd2BLQnwt6PtUu/G7fMJEtvAaoeAvcbuK9sQxCbB2p8CAE8tjqTQR+HIP/Osjvug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5085 Subject: Re: [dpdk-dev] [PATCH] doc: clarify implicit filtering in transfer rules 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 Sender: "dev" Hi Andrew, PSB Thanks, Ori > -----Original Message----- > From: dev On Behalf Of Andrew Rybchenko > Sent: Wednesday, September 1, 2021 6:11 PM >=20 > As per existing documentation, attribute "transfer", quote, "complements > the behavior of some pattern items such as > RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them". That > effectively confronts the idea of implicit filtering imposed by port_id > argument passed by flow create API. >=20 > This bit of documentation is vague, and having no implicit filtering is > unfriendly to applications which insert flow rules on specific ports base= d on > the source port IDs of the (not offloaded) incoming packets. >=20 > In order to address the problem, document the existence of the implicit > filtering. Use the term "weak" for this filtering as it implies the possi= bility to > override it by including explicit traffic source criteria in the flow pat= tern > (PORT_ID, PHY_PORT and the likes). >=20 > Signed-off-by: Andrew Rybchenko > --- > The topic was briefly discussed in mail thread [1]. >=20 > I'm not sure if the patch should have "Fixes:" tag. If it is really behav= iour > intended from the very beginning, it should be backported and > corresponding fixes in drivers should be backported as well. >=20 > [1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1- > ivan.malov@oktetlabs.ru/ >=20 > doc/guides/prog_guide/rte_flow.rst | 17 ++++++++++++++--- > doc/guides/rel_notes/deprecation.rst | 5 ----- > 2 files changed, 14 insertions(+), 8 deletions(-) >=20 > diff --git a/doc/guides/prog_guide/rte_flow.rst > b/doc/guides/prog_guide/rte_flow.rst > index 2b42d5ec8c..af54939418 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -171,13 +171,24 @@ When supported, this effectively enables an > application to reroute traffic not necessarily intended for it (e.g. com= ing from > or addressed to different physical ports, VFs or applications) at the de= vice > level. >=20 > -It complements the behavior of some pattern items such as `Item: > PHY_PORT`_ -and is meaningless without them. > - > When transferring flow rules, **ingress** and **egress** attributes > (`Attribute: Traffic direction`_) keep their original meaning, as if pr= ocessing > traffic emitted or received by the application. I know this is original code but what do we mean application? You assume that the application is the switch? Or the application is some DPDK application running on the PF? >=20 > +DPDK port used to create transfer rule is important since it implicitly > +adds filtering by it (similar to `Item: PORT_ID` with ``spec.id`` equal > +to the port ID and exact match mask) if no other items which specify > +source are present in the rule pattern (e.g. `Item: PHY_PORT`, `Item: > +VF` or explicit `Item: PORT_ID`). It means that by default ingress > +rules apply to traffic which comes from associated upstream switch > +port, i.e. physical network port for PF DPDK port, VF for VF > +representor. Egress rules transfer traffic transmitted via > +corresponding DPDK port, i.e. PF DPDK port or VF representor itself. > + To make sure I understand the direction should be defined as follows: Traffic from ---> to Wire --> VF =3D=3D> ingress direction. VF --> Wire =3D=3D> ingress direction. VF1 --> VF2 =3D=3D> ingress direction. VF 1--> VF2 representor =3D=3D> ingress. VF representor --> wire =3D=3D> egress. VF representor --> VF =3D=3D> egress > +It is still possible to apply transfer rule on a traffic originating > +from any switch port using wildcard mask in corresponding pattern item > +if underlying PMD supports it. > + > Pattern item > ~~~~~~~~~~~~ >=20 > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 76a4abfd6b..f1d290a911 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -134,11 +134,6 @@ Deprecation Notices > traffic direction to the represented entity or ethdev port itself > in DPDK 21.11. >=20 > -* ethdev: Flow API documentation is unclear if ethdev port used to creat= e > - a flow rule adds any implicit match criteria in the case of transfer r= ules. > - The semantics will be clarified in DPDK 21.11 and it will require fixe= s in > - drivers and applications which interpret it in a different way. > - > * ethdev: The flow API matching pattern structures, ``struct > rte_flow_item_*``, > should start with relevant protocol header. > Some matching pattern structures implements this by duplicating protoc= ol > header > -- > 2.30.2