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

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

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

OK for me.