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 08AEFA034F; Mon, 7 Jun 2021 11:42:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 977A84067E; Mon, 7 Jun 2021 11:42:21 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1FCBA40147 for ; Mon, 7 Jun 2021 11:42:20 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 6151C7F529; Mon, 7 Jun 2021 12:42:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 6151C7F529 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623058939; bh=AclwwzqLpC01LkOKhJro97uLgxu8XxmlzWpfxUVOLQU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Dtkq5G4z0z/WadPaUzbpDhdSmhd/HEZDaEDkX9BOBL4fh05phbvdSCmha/bdKN6Ky RbWS5glU4qQoF90eAVKwvaXVSpyG3rpqxWZZkpxPhZCm5cZKkFAVwwhZ/fxpZ9PfFH IeaLBbSJcyUq7m4cqT/7Xl/jcbY24gw/6rUhdXZM= To: Thomas Monjalon , Ori Kam , 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: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Mon, 7 Jun 2021 12:42:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2096515.Zf3HStYMcu@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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.