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

[Thomas Monjalon <thomas@monjalon.net>]

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.