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 8AB07A0C4E; Sun, 1 Aug 2021 15:23:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D42840143; Sun, 1 Aug 2021 15:23:55 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0582340140 for ; Sun, 1 Aug 2021 15:23:53 +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 EF89D7F51B; Sun, 1 Aug 2021 16:23:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru EF89D7F51B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1627824233; bh=qv+nwLxZMwkZH8RYuFa/5C/Uq9wQYRr7Za4BvmGOhL4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gCIPm2/9Uq56Iw4hlfIFCuU7ioEcrXr7aennfEsBmKKCNO/j3CfcyTLcp8bqJHHSs fYnVnIvVxyx+uoideULwVoX+pjuVDVbw4eHHDIvFEhF+8R84JaXyY++UxWj/wJofR3 j58C1aElpMTleQTwEyYD3ZpDZNbiB+f2X45l7gtE= To: Ori Kam , Eli Britstein , NBU-Contact-Thomas Monjalon , Ferruh Yigit 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> <1d0c3022-afb6-6526-cd47-8945a455899a@oktetlabs.ru> <62851a01-57ed-0e2c-8160-16699452bebc@oktetlabs.ru> From: Andrew Rybchenko Message-ID: Date: Sun, 1 Aug 2021 16:23:51 +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: 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 3:56 PM, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Sunday, August 1, 2021 3:44 PM >> Subject: Re: [PATCH 1/2] ethdev: announce flow API action PORT_ID changes >> >> Hi Ori, >> >> On 8/1/21 3:23 PM, Ori Kam wrote: >>> Hi Andrew, >>> >>> I think before we can change the API we must agree on the meaning of >> representor. >> >> The question is not directly related to a representor definition. >> Just indirectly. PORT_ID action makes sense for non-representor ports as >> well. >> >>> PSB more comments >>> >>>> -----Original Message----- >>>> From: Andrew Rybchenko >>>> Sent: Sunday, August 1, 2021 3:04 PM >>>> To: Eli Britstein ; NBU-Contact-Thomas Monjalon >>>> ; Ferruh Yigit ; Ori Kam >>>> >>>> Cc: dev@dpdk.org; Ilya Maximets ; Ajit Khaparde >>>> ; Matan Azrad ; >> Ivan >>>> Malov ; Viacheslav Galaktionov >>>> >>>> Subject: Re: [PATCH 1/2] ethdev: announce flow API action PORT_ID >>>> changes >>>> >>>> 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. >>>> >>> Agree, it is good that you created the announcement. >> >> Hopefully you agree that the area requires clarification and must be >> improved. I think so hot discussions really prove it. >> > +1 > >>> I think we should continue our discussion on what is a representor. >> >> Yes, but it is a hard topic. I'd like to unbind PORT_ID action from the >> discussion, since the action makes sense for non-representors as well. >> > If this can be done great, I'm for it, but I'm not sure it can be, but let's try. > >>> I think for current implementation the doc should say "direct / >>> matches traffic to / from the switch port which the selected DPDK >>> representor port is connected to or to DPDK port if this port is not a >> representor." >> >> IMHO it is better to keep the definition of the action simple and do not have >> any representor specifics in it. Representor is an ethdev port. If we direct >> traffic to an ethdev port, it should be received on the ethdev port regardless >> if it is a representor or not. >> It is better to avoid exceptions and special cases. >> > > Lets see if I understand correctly, you suggest that port action / item will be > for DPDK port, unless they are marked with some bit which means that > the traffic should be routed to the switch port which the DPDK port represent > am I correct? Here I'm talking about PORT_ID action only. As for details, I've tried to keep it out-of-scope of the deprecation notice. However, since we are going to break something here, it is better to break hard to be sure that every since usage is updated. So, I tend to to solution suggested by Ilya [1] which is similar to Linux kernel. I.e. add an enum with invalid zero value and two members to specify direction. [1] https://patches.dpdk.org/project/dpdk/patch/20210601111420.5549-1-ivan.malov@oktetlabs.ru/#133431 as for PORT_ID pattern item, I think ingress/egress attributes define direction. If it is an ingress flow rule, PORT_ID item should match traffic coming from represented entity in the case of port representor and associated network port in the case of ethdev port associated with it. In egress case it otherwise matches traffic sent using Tx burst via corresponding ethdev port. >>> If we go this way there is no need to change the API only the doc. >>> >>>>> 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. >>>> >>> To make sure I understand you are talking about a DPDK application >>> that is connected to number of ports and it is Eswitch manager, but it >>> doesn't use representors but the actual ports, right? >>> I think the definition I wrote above also works for this case. >> >> Other possible request is to direct traffic from phys port #0 to phys port #1 >> directly and say it in terms of PORT_ID action. >> > But we are talking using the switch layer(transfer mode) right? Yes. > Best, > Ori >> Thanks, >> Andrew. >> >>> Best, >>> Ori >>> >>>>>> >>>>>> 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 >>>>>> >>> >