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 B1486A0C55; Wed, 13 Oct 2021 18:42:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7828F410E0; Wed, 13 Oct 2021 18:42:58 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1BD5140151 for ; Wed, 13 Oct 2021 18:42:57 +0200 (CEST) Received: from localhost.localdomain (unknown [5.144.123.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id A70817F519; Wed, 13 Oct 2021 19:42:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru A70817F519 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1634143376; bh=EZClcjRSc26rfmAj1mfdRHJEHls9TewkJzW/cC5lubs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Gzuui0dQ/mELzr75o3QLRP/mnE+t1FtwVKwAT8eO7P1pdWh44TZiHKOJrBj/NAKYK hjoFbKJZeumcPBvCfYFakUjWAYynemPhmshj+LmGNmw+uXUu94NQlfMP2CAma8xBCD /eMghUOB+btcKPblKJ4ledvV8Zdr+6l2VyDUj0tw= From: Ivan Malov To: dev@dpdk.org Cc: Ferruh Yigit , Thomas Monjalon , Ori Kam Date: Wed, 13 Oct 2021 19:42:31 +0300 Message-Id: <20211013164243.21264-1-ivan.malov@oktetlabs.ru> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20211001134716.1608857-1-andrew.rybchenko@oktetlabs.ru> References: <20211001134716.1608857-1-andrew.rybchenko@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v4 00/12] ethdev: rework transfer flow API 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 RFC [1], action PORT_ID appears to be ambiguous. Its name suggests that matching traffic be sent to the ethdev with the specified ID, that is, to the application. However, in Open vSwitch, the action is used to send traffic to a remote entity represented by the given port, that is, in the opposite direction. Its interpretation across PMDs also varies. RFC [2] attempted to define action PORT_ID semantics in vSwitch sense. However, this solution would completely abandon the opposite meaning. One more effort, RFC [3], was meant to declare that the use of direction attributes in "transfer" flows assumed implicit filtering by the port ID appearing as the first argument in rte_flow_create(). However, not all PMDs require such filtering, so the RFC turned out rather disputable. Since then, all of that has been given more thought: 1. One should not attempt to fix action PORT_ID. Instead, two new actions should be introduced. The first one should send traffic to the given ethdev. The second one should send it to the represented entity. 2. Similar to (1), two new items should be defined. The first one should match traffic going down from the given ethdev. The second one should match traffic going up from the entity represented by that ethdev. 3. The application always knows which packets come through which ethdevs. So, as per (2), the application can use the new item to match traffic arriving from precise entities represented by the relevant ethdev IDs. 4. New items suggested in (2) do not require the use of direction attributes. These items define precise directions on their own. 5. As a consequence of (3) and (4), the problem of implicit filtering by rte_flow_create() port ID argument and direction attributes is no longer a blocker. The new items allow to dispose of it. The new items appear to be symmetrical to each other. So do the new actions. This requires that their names reflect the symmetry. Also, the names should respect the existing concept of port representors. By the looks of it, terms "PORT_REPRESENTOR" and "REPRESENTED_PORT" satisfy these requirements. However, currently, ethdevs associated with network ports are not considered as their representors. Such understanding is mentioned in the documentation, but it's not expressed in the code (see enum rte_eth_representor_type). The short of it, this patch series follows points (1-5) to rework support for "transfer" flows accordingly. On the way, a string of ambiguous pattern items (PF, VF, PHY_PORT) is deprecated. The patch series also updates PMDs which support item and action PORT_ID to add support for replacements (1-2). However, there're some exceptions: - Support for traffic source items in the case of net/mlx5 is really complicated. This series does not rework it. The PMD maintainer can do the job much better and test the new code accordingly; - Support for item REPRESENTED_PORT and both actions is not added to net/sfc. This will be done later on, in a separate series. Changes in v2: * New naming and reworked comments * New diagrams Changes in v3: * Diagram improvements * Spelling fixes Changes in v4: * Minor adjustments as per request by Ferruh Yigit Andrew Rybchenko (6): net/bnxt: support meta flow items to match on traffic source net/bnxt: support meta flow actions to overrule destinations net/enic: support meta flow actions to overrule destinations net/mlx5: support represented port flow action net/octeontx2: support port representor flow action net/sfc: support port representor flow item Ivan Malov (6): ethdev: add port representor item to flow API ethdev: add represented port item to flow API ethdev: add port representor action to flow API ethdev: add represented port action to flow API ethdev: deprecate hard-to-use or ambiguous items and actions ethdev: deprecate direction attributes in transfer flows app/test-pmd/cmdline_flow.c | 104 +++++++ doc/guides/nics/features/bnxt.ini | 4 + doc/guides/nics/features/enic.ini | 2 + doc/guides/nics/features/mlx5.ini | 1 + doc/guides/nics/features/octeontx2.ini | 1 + doc/guides/nics/features/sfc.ini | 1 + doc/guides/nics/mlx5.rst | 4 +- doc/guides/nics/octeontx2.rst | 5 +- doc/guides/nics/sfc_efx.rst | 4 + doc/guides/prog_guide/rte_flow.rst | 270 +++++++++++++++++- doc/guides/rel_notes/deprecation.rst | 18 +- doc/guides/rel_notes/release_21_11.rst | 8 + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 19 ++ drivers/net/bnxt/tf_ulp/ulp_rte_handler_tbl.c | 22 +- drivers/net/bnxt/tf_ulp/ulp_rte_parser.c | 161 ++++++++--- drivers/net/bnxt/tf_ulp/ulp_rte_parser.h | 12 +- drivers/net/enic/enic_fm_flow.c | 93 ++++-- drivers/net/mlx5/mlx5_flow_dv.c | 64 ++++- drivers/net/octeontx2/otx2_flow_parse.c | 16 +- drivers/net/sfc/sfc_mae.c | 72 +++++ lib/ethdev/rte_flow.c | 4 + lib/ethdev/rte_flow.h | 162 ++++++++++- 22 files changed, 927 insertions(+), 120 deletions(-) -- 2.20.1