From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 112A4A034F; Mon, 7 Jun 2021 15:21:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C9BEA4067E; Mon, 7 Jun 2021 15:21:58 +0200 (CEST) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by mails.dpdk.org (Postfix) with ESMTP id 8FF3540147 for ; Mon, 7 Jun 2021 15:21:57 +0200 (CEST) Received: (Authenticated sender: i.maximets@ovn.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 6D56424000F; Mon, 7 Jun 2021 13:21:54 +0000 (UTC) To: Ori Kam , Andrew Rybchenko , NBU-Contact-Thomas Monjalon , Ivan Malov , Eli Britstein , Ilya Maximets Cc: "dev@dpdk.org" , Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ajit Khaparde , Jerin Jacob , John Daley , Ferruh Yigit References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <365e2ab9-6ca2-961b-5e27-f2f46a2e32c6@oktetlabs.ru> <2096515.Zf3HStYMcu@thomas> From: Ilya Maximets Message-ID: Date: Mon, 7 Jun 2021 15:21:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: clarify flow action PORT ID semantics X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 6/7/21 2:08 PM, Ori Kam wrote: > > >> -----Original Message----- >> From: Andrew Rybchenko >> 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. Second half of the day (CET) is pretty much booked in my calendar. Tuesday or Wednesday might work on this week. Wednesday or Thursday might work on next week. >>> >> >> OK for me. > O.K. for me too. > Ori >