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 4B51DA0524; Wed, 2 Jun 2021 14:16:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3DA24069F; Wed, 2 Jun 2021 14:16:41 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id AF8FA40689 for ; Wed, 2 Jun 2021 14:16:40 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 920FC58081E; Wed, 2 Jun 2021 08:16:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Jun 2021 08:16:37 -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= CiW0Sx5OHzbQaLXPrRnqduywojBVUps89ZaHgYVzr6s=; b=2k5ImMOlb4yALIlr OnsKmHR2LRbibbF33ebE6QGGrGV8IoQldyAnzq6uZ7V7RcdOJP3cuVIXWG6uxWQB 4Gq3iFgVGkaoo707QiJtjNKq6uTnpqIv2V+jQoZXeTeWP45zmhzNyRsf5W4NI2VD b1LQRKCNVn/ddRsSxUi4sUw2Txbe5me21HheT/B85BXsVPoABhqJgShtC4c5nCts gjAMhVv12d+La/kCjNoO3XkqmvmNQQiLzBpzc/e93gThkk4h6ex5G8mCdBSOsFw6 8H45Pj9RgrgzTl6k38NlzFKwkXUqzQcGNl7YKIMMmp3qAcdiwopDwm6JEVQa39Wm wWM/mw== 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=fm2; bh=CiW0Sx5OHzbQaLXPrRnqduywojBVUps89ZaHgYVzr 6s=; b=m5qOI/Du9NfRgBk4SuaKeGzex9dJc4RltJ3J4DmffZKIAq8XFhuLFX/h6 yf7Eeo5jkkxi3QTeC6s88l8GW/0u/H8zzXaD2kVt8axUD4vLHiD6dTQ70wP+TntR AV9WQzkVcMXH0nrwUV3cPU+Pb5lvhraBZPikBSpZPQaoJ2BxZGybyNiRNunb2XQF 1k8qIni9iYCKJbNR1OyqDbzpQVqzwjHYcTSqYvIgK7DUwVWxE8abmI9CREJry6GP hXpn3/vodSJZ3UNX263vuwi4YTpRjwJfT0Hzfi7QG+IaI8Jq96poWmvIb+t1q0WM tEAKmT/3Wrr7vfKaChoFmGkQq3Ouw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeljedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Jun 2021 08:16:34 -0400 (EDT) From: Thomas Monjalon To: Ivan Malov , Ilya Maximets , Eli Britstein , Andrew Rybchenko Cc: dev@dpdk.org, Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ori Kam , Ajit Khaparde , Jerin Jacob , John Daley , Ferruh Yigit Date: Wed, 02 Jun 2021 14:16:33 +0200 Message-ID: <4411589.J5AvIlR3Bg@thomas> In-Reply-To: <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> 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" 01/06/2021 14:10, Ilya Maximets: > On 6/1/21 1:14 PM, Ivan Malov wrote: > > By its very name, action PORT_ID means that packets hit an ethdev with the > > given DPDK port ID. At least the current comments don't state the opposite. > > That said, since port representors had been adopted, applications like OvS > > have been misusing the action. They misread its purpose as sending packets > > to the opposite end of the "wire" plugged to the given ethdev, for example, > > redirecting packets to the VF itself rather than to its representor ethdev. > > Another example: OvS relies on this action with the admin PF's ethdev port > > ID specified in it in order to send offloaded packets to the physical port. > > > > Since there might be applications which use this action in its valid sense, > > one can't just change the documentation to greenlight the opposite meaning. > > This patch adds an explicit bit to the action configuration which will let > > applications, depending on their needs, leverage the two meanings properly. > > Applications like OvS, as well as PMDs, will have to be corrected when the > > patch has been applied. But the improved clarity of the action is worth it. > > > > The proposed change is not the only option. One could avoid changes in OvS > > and PMDs if the new configuration field had the opposite meaning, with the > > action itself meaning delivery to the represented port and not to DPDK one. > > Alternatively, one could define a brand new action with the said behaviour. > > We had already very similar discussions regarding the understanding of what > the representor really is from the DPDK API's point of view, and the last > time, IIUC, it was concluded by a tech. board that representor should be > a "ghost of a VF", i.e. DPDK APIs should apply configuration by default to > VF and not to the representor device: > https://patches.dpdk.org/project/dpdk/cover/20191029185051.32203-1-thomas@monjalon.net/#104376 > This wasn't enforced though, IIUC, for existing code and semantics is still mixed. Quoting myself from above link: "the representor port must be a real DPDK port, not a ghost." and "During the Technical Board yesterday, it was decided to go with Intel understanding of what is a representor, i.e. a ghost of the VF." and "we will continue to mix VF and representor operations with the same port ID. For the record, I believe it is very bad." > I still think that configuration should be applied to VF, and the same applies > to rte_flow API. IMHO, average application should not care if device is > a VF itself or its representor. Everything should work exactly the same. What means "work exactly the same"? Is it considering what is behind the representor silently, or considering the representor as a real port? There is a need to really consider representor port as any other port, and stop this ugly mix. I want to propose such change again for DPDK 21.11. To me the real solution is to use a bit in the port id of a representor for explicitly identifying the port behind the representor. This bit could be translated as a flag or a sign in testpmd text grammar. > I think this matches with the original idea/design of the switchdev functionality > in the linux kernel and also matches with how the average user thinks about > representor devices. There is no "average" user or application, just right and wrong. In the switchdev model, a representor is a port of a switch like any other port, not a ghost of its peer. > If some specific use-case requires to distinguish VF from the representor, > there should probably be a separate special API/flag for that. Yes, port ID of a representor must be the representor itself, and a bit can help reaching the port behind the representor.