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 A7A46A0524; Tue, 1 Jun 2021 16:36:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1AF2F40689; Tue, 1 Jun 2021 16:36:00 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id B887F40041 for ; Tue, 1 Jun 2021 16:35:58 +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 382B37F529; Tue, 1 Jun 2021 17:35:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 382B37F529 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1622558158; bh=vMsaTeIarUz0PRiComqmxVvVvrEbLgHwslPbWtG8qQ4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=yfwhd/XGYsXv+/FHGqjdRncgHceysgzsmjSmQ2aZhNgRyqM9PjD3i/sv91uzxZJSS CHrseUunInOwyi0FEEUtTutTmqS49nXqdJLYdj+7tgopgoq22D9cEKfWiGNPlI/zbG pTDqW+4T9Wv8R2Tl9hIQ9bjUbc0q+R7r4rv8UWwE= To: Eli Britstein , Ilya Maximets , Ivan Malov , dev@dpdk.org Cc: Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ori Kam , Ajit Khaparde , Jerin Jacob , John Daley , Thomas Monjalon , Ferruh Yigit References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> <9ed06b56-26e1-5812-e357-81147e699b3b@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <11ed17c8-a3f4-3fcb-b11f-7c4ee903b991@oktetlabs.ru> Date: Tue, 1 Jun 2021 17:35:58 +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: <9ed06b56-26e1-5812-e357-81147e699b3b@nvidia.com> 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/1/21 4:24 PM, Eli Britstein wrote: > > On 6/1/2021 3:10 PM, Ilya Maximets wrote: >> External email: Use caution opening links or attachments >> >> >> 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. > > It doesn't make any sense to attach the VF itself to OVS, but only its > representor. OvS is not the only DPDK application. > For the PF, when in switchdev mode, it is the "uplink representor", so > it is also a representor. Strictly speaking it is not a representor from DPDK point of view. E.g. representors have corresponding flag set which is definitely clear in the case of PF. > That said, OVS does not care of the type of the port. It doesn't matter > if it's an "upstream" or not, or if it's a representor or not. Yes, it is clear, but let's put OvS aside. Let's consider a DPDK application which has a number of ethdev port. Some may belong to single switch domain, some may be from different switch domains (i.e. different NICs). Can I use PORT_ID action to redirect ingress traffic to a specified ethdev port using PORT_ID action? It looks like no, but IMHO it is the definition of the PORT_ID action. >> 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. > I am not sure how this is related. >> >> 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. >> 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. > Right. This is the way representors work. It is fully aligned with > configuration of OVS-kernel. >> >> If some specific use-case requires to distinguish VF from the >> representor, >> there should probably be a separate special API/flag for that. >> >> Best regards, Ilya Maximets.