From patchwork Tue Sep 7 12:51:57 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ivan Malov X-Patchwork-Id: 98176 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BC4FCA0C46; Tue, 7 Sep 2021 14:52:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 550D7410ED; Tue, 7 Sep 2021 14:52:06 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 9C518410EC for ; Tue, 7 Sep 2021 14:52:04 +0200 (CEST) Received: from localhost.localdomain (unknown [5.144.121.0]) (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 08DD47F53A; Tue, 7 Sep 2021 15:52:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 08DD47F53A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1631019124; bh=bGOAOWA0OhyxWot5MUv7yPHNhMd4K/CjqvuyCilhs8A=; h=From:To:Cc:Subject:Date; b=xiVXBdriEKV3pugtycKXSGqVVroMRsKFsuuEZSdZG7uldejTpM0uHiMOun8THg1S+ OSJ9Pw3HLiR2M8aKM/qWtVNGr32NjM8Pe9t6C9FSTdtZ2JiKzVjJHtBMV7rKUWZIr+ ZOKyHvG/EeyEWbiGEOeaYnVPqwjXHGl8zvwsl06Y= From: Ivan Malov To: dev@dpdk.org Cc: Ori Kam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Date: Tue, 7 Sep 2021 15:51:57 +0300 Message-Id: <20210907125157.3843-1-ivan.malov@oktetlabs.ru> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [dpdk-dev] [RFC PATCH] ethdev: clarify flow attribute and action port ID semantics 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" Problems: 1) Existing item PORT_ID and action PORT_ID are ambiguous because one can consider the port in question as either an ethdev or an embedded switch entity wired to it, as per the use case, which is not expressed clearly in code and documentation. 2) Attributes "ingress" and "egress" may not make sense in flows with "transfer" attribute for some PMDs. Furthermore, such PMDs may face a related problem (see below). 3) A PMD may not be able to handle "transfer" rules on all ethdevs it serves. It may have only one (admin) ethdev capable of that. Applications should be able to take this into account and submit "transfer" rules on that specific ethdev. However, meaning of attributes "ingress" and "egress" might be skewed in this case as the ethdev used to make flow API calls is just a technical entry point. In order to solve problem (1)ΒΈ one should recognise the existence of two major application models: traffic consumer / generator and a vSwitch / forwarder. To the latter, ethdevs used to perform Rx / Tx burst calls are simply vSwitch ports. Requesting HW offloads on these ports implies referring to e-switch ports that correspond to them at the lowest, e-switch, level. This way, suggested terminology is clear and concise. The patch suggests using item / action PORT_ID sub-variants to disambiguate the meaning. In order to avoid breaking existing behaviour in Open vSwitch DPDK offload, the sub-variant for e-switch port is declared with enum value of zero. In order to solve problems (2) and (3), one needs to recognise the existence of two paradigms of handling "transfer" rules in PMDs. If the given PMD needs to "proxy" handling of "transfer" rules via an admin ethdev, this must not be done implicitly as the application must know the true ethdev responsible for handling the flows in order to avoid detaching it before all "transfer" rules get properly dismantled. The patch suggests to use a generic helper to let applications discover the paradigm in use and, if need be, communicate flow rules through the discovered "proxy" ethdev. Signed-off-by: Ivan Malov --- This proposal is an alternative to previously suggested RFCs, [1] and [2]. It covers several related problems and suggests clear API contract to let vSwitch applications use item PORT_ID and action PORT_ID to refer to e-switch ports thus preserving existing sense. [1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1-ivan.malov@oktetlabs.ru/ [2] https://patches.dpdk.org/project/dpdk/patch/20210903074610.313622-1-andrew.rybchenko@oktetlabs.ru/ --- lib/ethdev/rte_flow.h | 140 ++++++++++++++++++++++++++++++++---------- 1 file changed, 107 insertions(+), 33 deletions(-) diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index 70f455d47d..bf2b5e752c 100644 --- a/lib/ethdev/rte_flow.h +++ b/lib/ethdev/rte_flow.h @@ -82,22 +82,32 @@ struct rte_flow_attr { uint32_t ingress:1; /**< Rule applies to ingress traffic. */ uint32_t egress:1; /**< Rule applies to egress traffic. */ /** - * Instead of simply matching the properties of traffic as it would - * appear on a given DPDK port ID, enabling this attribute transfers - * a flow rule to the lowest possible level of any device endpoints - * found in the pattern. - * - * When supported, this effectively enables an application to - * re-route 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 - * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them. - * - * When transferring flow rules, ingress and egress attributes keep - * their original meaning, as if processing traffic emitted or - * received by the application. + * This "transfers" the rule from the ethdev level to the embedded + * switch (e-switch) level, where it's possible to match traffic + * not necessarily going to the ethdev where the flow is created + * and redirect it to endpoints otherwise not necessarily + * accessible from rules having no such attribute. + * + * Applications willing to use attribute "transfer" should detect its + * paradigm implemented inside the PMD. The paradigms are as follows: + * + * - The PMD supports handling "transfer" flow rules on any ethdevs + * it serves. With this paradigm, rte_flow_pick_transfer_proxy() + * call returns (-ENOTSUP) for all ethdevs backed by the PMD. + * Attributes "ingress" and "egress" are valid and preserve + * their original meaning, at application standpoint. Also, + * these attributes typically set some implicit filtering. + * + * - The PMD only supports handling "transfer" flow rules on some + * specific ethdev pointed out by rte_flow_pick_transfer_proxy(). + * Typically, it's an admin PF ethdev backing a group of VF + * representor ethdevs. In this case, attributes "ingress" + * and "egress" cannot maintain their original meaning as + * the ethdev used to handle "transfer" flow rules is + * just a technical entry point and does not mean any + * implicit filtering. Attribute "egress" is rejected, + * and "ingress" (redundant) means traffic ingressing + * the embedded switch from any of its endpoints. */ uint32_t transfer:1; uint32_t reserved:29; /**< Reserved, must be zero. */ @@ -191,8 +201,9 @@ enum rte_flow_item_type { /** * [META] * - * Matches traffic originating from (ingress) or going to (egress) a - * given DPDK port ID. + * Matches traffic originating from (ingress) or going to (egress) the + * port which, depending on the item sub-variant, is the given ethdev + * or the opposite end of the "wire" attached to this ethdev. * * See struct rte_flow_item_port_id. */ @@ -679,29 +690,61 @@ static const struct rte_flow_item_phy_port rte_flow_item_phy_port_mask = { }; #endif +/** Port types for use with item PORT_ID and action PORT_ID */ +enum rte_flow_item_port_id_type { + /** + * The port in question is an embedded switch entity connected + * to or represented by the given ethdev / vSwitch port. + * + * +--------------------------+---------------------------+ + * | Ethdev / vSwitch Port | Embedded Switch Entity | + * +--------------------------+---------------------------+ + * | PF / VF <-> Network Port | + * +------------------------------------------------------+ + * | PF / VF Representor <-> PF / VF Itself | + * +------------------------------------------------------+ + */ + RTE_FLOW_PORT_TYPE_ESWITCH = 0, + + /** + * The port in question is an ethdev or, synonymously, + * a DPDK-backed vSwitch port. + */ + RTE_FLOW_PORT_TYPE_ETHDEV, +}; + /** * RTE_FLOW_ITEM_TYPE_PORT_ID * - * Matches traffic originating from (ingress) or going to (egress) a given - * DPDK port ID. + * Matches traffic originating from (ingress) or going to (egress) the + * port which, depending on the item sub-variant, is the given ethdev + * or the opposite end of the "wire" attached to this ethdev. * - * Normally only supported if the port ID in question is known by the - * underlying PMD and related to the device the flow rule is created - * against. + * Typically, the ethdev referring to the port in question must be served + * by the same PMD as that of the ethdev used to create the flow rule. + * Also, the port must normally belong to the same physical board. * - * This must not be confused with @p PHY_PORT which refers to the physical - * port of a device, whereas @p PORT_ID refers to a struct rte_eth_dev - * object on the application side (also known as "port representor" - * depending on the kind of underlying device). + * This must not be confused with item @p PHY_PORT + * which refers specifically to a physical port. */ +RTE_STD_C11 struct rte_flow_item_port_id { - uint32_t id; /**< DPDK port ID. */ + /** Synonymous defines for ethdev ID property */ + union { + /** Ethdev (vSwitch port) ID */ + uint32_t ethdev_id; + /** Compatibility alias to avoid breaking legacy applications */ + uint32_t id; + }; + + /** Port type (item sub-variant) */ + enum rte_flow_item_port_id_type type; }; /** Default mask for RTE_FLOW_ITEM_TYPE_PORT_ID. */ #ifndef __cplusplus static const struct rte_flow_item_port_id rte_flow_item_port_id_mask = { - .id = 0xffffffff, + .ethdev_id = 0xffffffff, }; #endif @@ -1976,7 +2019,8 @@ enum rte_flow_action_type { RTE_FLOW_ACTION_TYPE_PHY_PORT, /** - * Directs matching traffic to a given DPDK port ID. + * Depending on the port type, directs matching traffic either to the + * given ethdev or to the opposite end of the "wire" attached to it. * * See struct rte_flow_action_port_id. */ @@ -2635,14 +2679,26 @@ struct rte_flow_action_phy_port { /** * RTE_FLOW_ACTION_TYPE_PORT_ID * - * Directs matching traffic to a given DPDK port ID. + * Depending on the port type, directs matching traffic either to the + * given ethdev or to the opposite end of the "wire" attached to it. * * @see RTE_FLOW_ITEM_TYPE_PORT_ID */ +RTE_STD_C11 struct rte_flow_action_port_id { - uint32_t original:1; /**< Use original DPDK port ID if possible. */ + uint32_t original:1; /**< Use original ethdev ID if possible. */ uint32_t reserved:31; /**< Reserved, must be zero. */ - uint32_t id; /**< DPDK port ID. */ + + /** Synonymous defines for ethdev ID property */ + union { + /** Ethdev (vSwitch port) ID */ + uint32_t ethdev_id; + /** Compatibility alias to avoid breaking legacy applications */ + uint32_t id; + }; + + /** Port type (action sub-variant) */ + enum rte_flow_item_port_id_type type; }; /** @@ -4288,6 +4344,24 @@ rte_flow_tunnel_item_release(uint16_t port_id, struct rte_flow_item *items, uint32_t num_of_items, struct rte_flow_error *error); + +/** + * Locate the "proxy" ethdev to handle "transfer" flow rules + * for the given ethdev. If the API returns (-ENOTSUP), the + * caller should assume that no "proxying" is required. + * + * @param port_id + * Ethdev ID that potentially needs a "proxy" + * @param[out] proxy_port_id + * The "proxy" port through which "transfer" rules must be communicated + * + * @return + * 0 on success, a negative error code otherwise + */ +__rte_experimental +int +rte_flow_pick_transfer_proxy(uint16_t port_id, + uint16_t *proxy_port_id); #ifdef __cplusplus } #endif