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

[Ivan Malov]

On 01/06/2021 17:44, Eli Britstein wrote:
> 
> 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.

Not the focus, but rather the most pictorial example.

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

-- 
Ivan M