Re: [dpdk-dev] [RFC PATCH] ethdev: clarify flow action PORT ID semantics

[Eli Britstein <elibr@nvidia.com>]

On 6/1/2021 5:35 PM, Andrew Rybchenko wrote:
> External email: Use caution opening links or attachments
>
>
> 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.
True. It is just the focus of this commit message is OVS.
>
>> 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.
This is the per-PMD responsibility. The API should not care.
>
>> 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.

Let's separate API from implementation. By API point of view, yes, the 
user may request it. Nothing wrong with it.

 From implementation point of view - yes, it might fail, but not for 
sure, even if on different NICs. Maybe the HW of a certain vendor has 
the capability to do it?

We can't know, so I think the API should allow it.

>
>>> 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.
>> 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.