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 5AC92A0524; Wed, 2 Jun 2021 14:53:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CF8104069F; Wed, 2 Jun 2021 14:53:43 +0200 (CEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mails.dpdk.org (Postfix) with ESMTP id 67BF140689 for ; Wed, 2 Jun 2021 14:53:42 +0200 (CEST) Received: (Authenticated sender: i.maximets@ovn.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 21305E0002; Wed, 2 Jun 2021 12:53:38 +0000 (UTC) To: Thomas Monjalon , Ivan Malov , Ilya Maximets , Eli Britstein , Andrew Rybchenko Cc: dev@dpdk.org, Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ori Kam , Ajit Khaparde , Jerin Jacob , John Daley , Ferruh Yigit References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> <4411589.J5AvIlR3Bg@thomas> From: Ilya Maximets Message-ID: <5fcaa3c8-a777-b4f1-2a2a-9e8ee2df827b@ovn.org> Date: Wed, 2 Jun 2021 14:53:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <4411589.J5AvIlR3Bg@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [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" On 6/2/21 2:16 PM, Thomas Monjalon wrote: > 01/06/2021 14:10, Ilya Maximets: >> On 6/1/21 1:14 PM, Ivan Malov wrote: >>> 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. >> >> We had already very similar discussions regarding the understanding of what >> the representor really is from the DPDK API's point of view, and the last >> time, IIUC, it was concluded by a tech. board that representor should be >> a "ghost of a VF", i.e. DPDK APIs should apply configuration by default to >> VF and not to the representor device: >> https://patches.dpdk.org/project/dpdk/cover/20191029185051.32203-1-thomas@monjalon.net/#104376 >> This wasn't enforced though, IIUC, for existing code and semantics is still mixed. > > Quoting myself from above link: > "the representor port must be a real DPDK port, not a ghost." > and > "During the Technical Board yesterday, it was decided to go with Intel > understanding of what is a representor, i.e. a ghost of the VF." > and > "we will continue to mix VF and representor operations > with the same port ID. For the record, I believe it is very bad." > >> I still think that configuration should be applied to VF, and the same applies >> to rte_flow API. IMHO, average application should not care if device is >> a VF itself or its representor. Everything should work exactly the same. > > What means "work exactly the same"? > Is it considering what is behind the representor silently, > or considering the representor as a real port? Check ut my other email where I described some workflows and how, I think, they should work. Hopefully that will answer this question. (This email arrived while I was writing another one, so I had no chance to read this question). > > There is a need to really consider representor port as any other port, > and stop this ugly mix. I want to propose such change again for DPDK 21.11. > To me the real solution is to use a bit in the port id of a representor > for explicitly identifying the port behind the representor. > This bit could be translated as a flag or a sign in testpmd text grammar. This makes sense. > >> I think this matches with the original idea/design of the switchdev functionality >> in the linux kernel and also matches with how the average user thinks about >> representor devices. > > There is no "average" user or application, just right and wrong. > In the switchdev model, a representor is a port of a switch like > any other port, not a ghost of its peer. > >> If some specific use-case requires to distinguish VF from the representor, >> there should probably be a separate special API/flag for that. > > Yes, port ID of a representor must be the representor itself, > and a bit can help reaching the port behind the representor. I still think that the logic should be opposite, i.e. special bit should be set to identify that we want to reach the representor and not the port behind it. But we discussed this already several times and I also wrote some of the thoughts in the other email that I just sent. Best regards, Ilya Maximets.