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

[Andrew Rybchenko]

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