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 D48EEA0524; Tue, 1 Jun 2021 13:14:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B3E840689; Tue, 1 Jun 2021 13:14:27 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 7CE9440041 for ; Tue, 1 Jun 2021 13:14:26 +0200 (CEST) Received: from localhost.localdomain (unknown [188.242.7.54]) (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 CBF917F502; Tue, 1 Jun 2021 14:14:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru CBF917F502 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1622546065; bh=ZerdTMj0raviu/8b2HnBORLinWeJpEda00G6iff4D78=; h=From:To:Cc:Subject:Date; b=vYC5Pxs57Ad9O1CI6KfaZ+kqOJnfUyI01yrSKgyxDynM6slGYM1Sb6MkFOtpyyc7f sVcXm0T71Jqr14PLUxYoXExWpNZrcUTAQ1Jr6YsMqTkBhFBlT9uVABmj49iXcPys0U ajTbvfSsiFJ89ZJXjFroVElXpGwI+bxfZKf3e9to= From: Ivan Malov To: dev@dpdk.org Cc: Eli Britstein , Ilya Maximets , Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ori Kam , Ajit Khaparde , Jerin Jacob , John Daley , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Date: Tue, 1 Jun 2021 14:14:20 +0300 Message-Id: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [RFC PATCH] ethdev: clarify flow 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" By its very name, action PORT_ID means that packets hit an ethdev with the given DPDK port ID. At least the current comments don't state the opposite. That said, since port representors had been adopted, applications like OvS have been misusing the action. They misread its purpose as sending packets to the opposite end of the "wire" plugged to the given ethdev, for example, redirecting packets to the VF itself rather than to its representor ethdev. Another example: OvS relies on this action with the admin PF's ethdev port ID specified in it in order to send offloaded packets to the physical port. Since there might be applications which use this action in its valid sense, one can't just change the documentation to greenlight the opposite meaning. This patch adds an explicit bit to the action configuration which will let applications, depending on their needs, leverage the two meanings properly. Applications like OvS, as well as PMDs, will have to be corrected when the patch has been applied. But the improved clarity of the action is worth it. The proposed change is not the only option. One could avoid changes in OvS and PMDs if the new configuration field had the opposite meaning, with the action itself meaning delivery to the represented port and not to DPDK one. Alternatively, one could define a brand new action with the said behaviour. One may also consider clarifying item PORT_ID meaning in a separate change. Signed-off-by: Ivan Malov --- lib/ethdev/rte_flow.h | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index 961a5884f..f45937bd7 100644 --- a/lib/ethdev/rte_flow.h +++ b/lib/ethdev/rte_flow.h @@ -2635,13 +2635,22 @@ struct rte_flow_action_phy_port { /** * RTE_FLOW_ACTION_TYPE_PORT_ID * - * Directs matching traffic to a given DPDK port ID. + * Directs matching traffic to an ethdev with the given DPDK port ID or + * to the upstream port (the peer side of the wire) corresponding to it. + * + * It's assumed that it's the PMD (typically, its instance at the admin + * PF) which controls the binding between a (representor) ethdev and an + * upstream port. Typical bindings: VF rep. <=> VF, PF <=> network port. + * If the PMD instance is unaware of the binding between the ethdev and + * its upstream port (or can't control it), it should reject the action + * with the upstream bit specified and log an appropriate error message. * * @see RTE_FLOW_ITEM_TYPE_PORT_ID */ struct rte_flow_action_port_id { uint32_t original:1; /**< Use original DPDK port ID if possible. */ - uint32_t reserved:31; /**< Reserved, must be zero. */ + uint32_t upstream:1; /**< Use the upstream port for this one. */ + uint32_t reserved:30; /**< Reserved, must be zero. */ uint32_t id; /**< DPDK port ID. */ }; -- 2.20.1