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

[Ilya Maximets]

On 6/7/21 2:08 PM, Ori Kam wrote:
> 
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
>> semantics
>>
>> On 6/7/21 11:28 AM, Thomas Monjalon wrote:
>>> 03/06/2021 11:55, Andrew Rybchenko:
>>>> On 6/3/21 12:18 PM, Ori Kam wrote:
>>>>> Sorry but OVS got it right, this is the idea to send packet to the
>>>>> VF not to the representor, I think that our first discussion should
>>>>> be what is a representor, I know that there are a lot threads about it but
>> it is steel unclear.
>>>>
>>>> Yes, really unclear. I'd like to highlight again that the problem is
>>>> not with representors only (as described and discussed in the
>>>> thread).
>>>>
>>>>> From my understanding representor is a shadow of a VF This shadow
>>>>> has two functionalities:
>>>>> 1. data
>>>>> It should receive any packet that was sent from the VF and was not
>>>>> routed to any other destination. And vise versa any traffic sent on the
>> representor.
>>>>> should arrive to the corresponding VF.
>>>>> What use case do you see for sending a packet to the representor?
>>>>>
>>>>> 2. control
>>>>> allow to modify the VF from DPDK application.
>>>>>
>>>>> Regarding the 1 point of the data, I don't see any sense if routing traffic
>> to representor.
>>>>> While on point 2 control their maybe some cases that we want to
>>>>> configure the representor itself and not the VF for example changing
>> mtu.
>>>>
>>>> IMO if so there is a big inconsistency here with statistics (just an
>>>> example, which is simply to discuss).
>>>> On one hand packet/byte stats should say how much data is
>>>> received/sent by the DPDK application via the port (yes, shadow, but
>>>> still an ethdev port).
>>>> On the other hand you say that it is a shadow and it should return VF
>>>> stats.
>>>
>>> I see emails don't work well to conclude on how to manage representors.
>>> I propose working in live meetings so we can try to align our views on
>>> a virtual whiteboard and interactively ask questions.
>>> Participants in those meetings could work on documenting what is the
>>> view of a representor as a first step.
>>> Second step, it should be easier to discuss the API.
>>>
>>> If you agree, I will plan a first meeting where we can discuss what is
>>> a representor in our opinions.
>>> The meeting time would be 4pm UTC.
>>> For the day, I would propose this Thursday 10 if it works for
>>> everybody involved.

Second half of the day (CET) is pretty much booked in my calendar.  Tuesday
or Wednesday might work on this week.  Wednesday or Thursday might work on
next week.

>>>
>>
>> OK for me.
> O.K. for me too.
> Ori
>