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.
