On 6/1/21 4:24 PM, Eli Britstein wrote: > > On 6/1/2021 3:10 PM, Ilya Maximets wrote: >> External email: Use caution opening links or attachments >> >> >> 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. > > It doesn't make any sense to attach the VF itself to OVS, but only its > representor.
OvS is not the only DPDK application. > For the PF, when in switchdev mode, it is the "uplink representor", so > it is also a representor. Strictly speaking it is not a representor from DPDK point of view. E.g. representors have corresponding flag set which is definitely clear in the case of PF. > That said, OVS does not care of the type of the port. It doesn't matter > if it's an "upstream" or not, or if it's a representor or not. Yes, it is clear, but let's put OvS aside. Let's consider a DPDK application which has a number of ethdev port. Some may belong to single switch domain, some may be from different switch domains (i.e. different NICs). Can I use PORT_ID action to redirect ingress traffic to a specified ethdev port using PORT_ID action? It looks like no, but IMHO it is the definition of the PORT_ID action. >> 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-tho...@monjalon.net/#104376 >> >> This wasn't enforced though, IIUC, for existing code and semantics is >> still mixed. > I am not sure how this is related. >> >> 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. >> 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. > Right. This is the way representors work. It is fully aligned with > configuration of OVS-kernel. >> >> If some specific use-case requires to distinguish VF from the >> representor, >> there should probably be a separate special API/flag for that. >> >> Best regards, Ilya Maximets.
