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 9529FA0C4E; Sun, 1 Aug 2021 14:04:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D18640143; Sun, 1 Aug 2021 14:04:04 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id DCDA340140 for ; Sun, 1 Aug 2021 14:04:01 +0200 (CEST) Received: from [192.168.100.116] (unknown [37.139.99.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BB07D7F51B; Sun, 1 Aug 2021 15:04:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru BB07D7F51B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1627819441; bh=zjTXZUKRizc+6DqFBy4RllOaxIqDGmCN9lr8m8JZp9w=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Q3GmCb14+Ac1JtUJWp//9XsyHQ88SUsDzlDXeN1/rNUmkOHPgceHpIRHY5XeWNDAG Nlwl9e7AOCSfgl0R57f3qR+NGS6qqciTQJIU43A6crPVGzsYpAJSLqfLKEGpr5q/8I SaGIahqTvLQUyMiA6EoyxuPp7vquDuAFYsxPMkc4= To: Eli Britstein , Thomas Monjalon , Ferruh Yigit , Ori Kam Cc: dev@dpdk.org, Ilya Maximets , Ajit Khaparde , Matan Azrad , Ivan Malov , Viacheslav Galaktionov References: <20210801102214.1566104-1-andrew.rybchenko@oktetlabs.ru> <49eca7ed-ad3b-d47c-99d1-9ac109efc31a@nvidia.com> From: Andrew Rybchenko Message-ID: <1d0c3022-afb6-6526-cd47-8945a455899a@oktetlabs.ru> Date: Sun, 1 Aug 2021 15:03:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <49eca7ed-ad3b-d47c-99d1-9ac109efc31a@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: announce flow API action PORT_ID changes 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" On 8/1/21 1:57 PM, Eli Britstein wrote: > > On 8/1/2021 1:22 PM, Andrew Rybchenko wrote: >> External email: Use caution opening links or attachments >> >> >> 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. >> >> The documentation must be clarified and rte_flow_action_port_id structure >> should be extended to support both meanings. > > I think the only clarification needed is that PORT_ID acts as if > rte_eth_tx_burst is called with the specified port-id. Sorry, but I still think that it is opposite meaning to the current documentation which says "Directs matching traffic to a given DPDK port ID." Since it happens on switching level (transfer rule) "to a given DPDK port" means that it will be received on a given DPDK port. Anyway, the goal of the deprecation notice is to highlight that it must be fixed and ensure that we can choose right decision even if it breaks API/ABI. > Regarding representors, it's not different. When using TX on a > representor port, the packets appear as RX on its represented port. > > Please elaborate if there is a use case for the PORT_ID~ in which the > app can get the packets using rte_eth_rx_burst on the specified port-id. Multi-home host with a NIC with two physical ports and two PFs used by DPDK app with layer 3 (IP addresses). Different cores used to handle traffic from different ports plus routing in DPDK app. If traffic to port #0 IP address is received on phys port #1, it is useful to redirect traffic to port ID 0 directly to have these packets on correct CPU cores from the very beginning to avoid SW mechanisms to pass from port #1 CPU cores to port #0 CPU cores. >> >> Signed-off-by: Andrew Rybchenko >> --- >>   doc/guides/rel_notes/deprecation.rst | 5 +++++ >>   1 file changed, 5 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index d9c0e65921..6e6413c89f 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -158,3 +158,8 @@ Deprecation Notices >>   * security: The functions ``rte_security_set_pkt_metadata`` and >>     ``rte_security_get_userdata`` will be made inline functions and >> additional >>     flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. >> + >> +* ethdev: Definition of the flow API action PORT_ID is ambiguous and >> needs >> +  clarification. Structure rte_flow_action_port_id will be extended to >> +  specify traffic direction to represented entity or ethdev port >> itself in >> +  DPDK 21.11. >> -- >> 2.30.2 >>