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

From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Thomas Monjalon <thomas@monjalon.net>, Ori Kam <orika@nvidia.com>,
	Ivan Malov <Ivan.Malov@oktetlabs.ru>,
	Eli Britstein <elibr@nvidia.com>,
	Ilya Maximets <i.maximets@ovn.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Smadar Fuks <smadarf@marvell.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Kishore Padmanabha <kishore.padmanabha@broadcom.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Jerin Jacob <jerinj@marvell.com>, John Daley <johndale@cisco.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: clarify flow action PORT ID semantics
Date: Mon, 7 Jun 2021 12:42:19 +0300	[thread overview]
Message-ID: <d8e0d8c5-5e4c-531f-67cc-4477e6029042@oktetlabs.ru> (raw)
In-Reply-To: <2096515.Zf3HStYMcu@thomas>

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.