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

[Ori Kam]

> -----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.
> >
> 
> OK for me.
O.K. for me too.
Ori