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 5C536A0C45; Wed, 1 Sep 2021 17:11:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6FA94013F; Wed, 1 Sep 2021 17:11:18 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id CD6EC40041 for ; Wed, 1 Sep 2021 17:11:17 +0200 (CEST) Received: by shelob.oktetlabs.ru (Postfix, from userid 122) id 5D8E37F6C2; Wed, 1 Sep 2021 18:11:17 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shelob.oktetlabs.ru X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_DISCARD, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from aros.oktetlabs.ru (aros.oktetlabs.ru [192.168.38.17]) by shelob.oktetlabs.ru (Postfix) with ESMTP id 15C437F6C0; Wed, 1 Sep 2021 18:11:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 15C437F6C0 Authentication-Results: shelob.oktetlabs.ru/15C437F6C0; dkim=none; dkim-atps=neutral From: Andrew Rybchenko To: Thomas Monjalon , Ferruh Yigit , Ori Kam Cc: dev@dpdk.org, Eli Britstein , Ilya Maximets , Ajit Khaparde , Matan Azrad , Ivan Malov , Viacheslav Galaktionov Date: Wed, 1 Sep 2021 18:11:04 +0300 Message-Id: <20210901151104.3923889-1-andrew.rybchenko@oktetlabs.ru> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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" 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. This bit of documentation is vague, and having no implicit filtering is unfriendly to applications which insert flow rules on specific ports based on the source port IDs of the (not offloaded) incoming packets. In order to address the problem, document the existence of the implicit filtering. Use the term "weak" for this filtering as it implies the possibility to override it by including explicit traffic source criteria in the flow pattern (PORT_ID, PHY_PORT and the likes). Signed-off-by: Andrew Rybchenko --- The topic was briefly discussed in mail thread [1]. I'm not sure if the patch should have "Fixes:" tag. If it is really behaviour intended from the very beginning, it should be backported and corresponding fixes in drivers should be backported as well. [1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1-ivan.malov@oktetlabs.ru/ doc/guides/prog_guide/rte_flow.rst | 17 ++++++++++++++--- doc/guides/rel_notes/deprecation.rst | 5 ----- 2 files changed, 14 insertions(+), 8 deletions(-) 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. coming from or addressed to different physical ports, VFs or applications) at the device level. -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 processing traffic emitted or received by the application. +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. + +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 ~~~~~~~~~~~~ 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. -* ethdev: Flow API documentation is unclear if ethdev port used to create - a flow rule adds any implicit match criteria in the case of transfer rules. - The semantics will be clarified in DPDK 21.11 and it will require fixes 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 protocol header -- 2.30.2