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 5DFA8A034F; Mon, 7 Jun 2021 10:28:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CD12C4067E; Mon, 7 Jun 2021 10:28:13 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 3F9D840147 for ; Mon, 7 Jun 2021 10:28:12 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 5F9C8580786; Mon, 7 Jun 2021 04:28:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 07 Jun 2021 04:28:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= ga656u0n/QMCdHIuhQPEhFcVYZR/+zEZYEZ9pH1Qq58=; b=U5epYDvwgWWMh8sX ewtTFmqVyLtjs7z9Ab5obREejaC32ue7H8tJ3VT0MndJku4w8k7UoiYhlRGgV+AZ 1g8rT0u4QrbSok3IMCiIENVYSgvVfMqUYkFYb4KotNiKa8XAykMM60OM0+Vs9tak FlG5qv+LBQBnS9ZpmKLe/38XqMoCMoc6mIRyDZlXOweD7QNuND54LdN+xJqt4THo gaFCnKY0nSn42QTypp93oCZhPOoky3rRNpZreP9O7voUjDOwrPEm+WQi2IYywKaN tgPisNvpTVfoaG6OIL6rtlKYn/KUcU67s3fNuHfSvJA299WqvsgzkXjY8u+4HRJ3 j/tLEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=ga656u0n/QMCdHIuhQPEhFcVYZR/+zEZYEZ9pH1Qq 58=; b=WKgVtf6uAydG+kZgy8P98x4a1YdiieYjFjlqDGzXFWpk31jDJuI2F5VQY bKvkJzbWOqE2pfi5HQOsNsXu5PffAouoJiy6zdpRlgwVEw3Vt8rXtr+VhIvGgccx fnyRlv/XgRtqZ51yEcThpL9zgNYHDeNGQokwLtbyujGdSlpVwKy4aDpN7/fgYrGQ x8Nz/iIBZMn3MNA9QMSD3z+qwYW9qM3vv0UJCzcevA4OSra9qBgk4n6l+J3/+463 J8BFWr+y9N9jE8CxHmUUnok1SWjJJIuUUf5TN5r8vAp2W0qc5k34Dh/CVbZb/YUC JNHfV4T3dbx0STSy481aZfrv8OcNw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtjedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 7 Jun 2021 04:28:07 -0400 (EDT) From: Thomas Monjalon To: 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 , Andrew Rybchenko Date: Mon, 07 Jun 2021 10:28:05 +0200 Message-ID: <2096515.Zf3HStYMcu@thomas> In-Reply-To: <365e2ab9-6ca2-961b-5e27-f2f46a2e32c6@oktetlabs.ru> References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <365e2ab9-6ca2-961b-5e27-f2f46a2e32c6@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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.