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 A1488A0524; Wed, 2 Jun 2021 11:57:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D67E4069F; Wed, 2 Jun 2021 11:57:19 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2084.outbound.protection.outlook.com [40.107.236.84]) by mails.dpdk.org (Postfix) with ESMTP id 8484940689 for ; Wed, 2 Jun 2021 11:57:17 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kjNwshsSGvpkh1SutltVO63XjPpLcxaTvHKKqPXL8IXKiNUlc8nJ/U0fBEmriQ4GJvCEWpbY+1D26VLO8db6l7klquRFlfAgNoxsW3LNrycuKk709L2944ocFGHWGyM2JHg/FdKbwDKmi4j8eu0HUgJPSzFMQgHVbz4nyUc83Ql1ncC8/H7kJKJF0LejdQHxJsRbH+ybXdVpQpVmccr0QfrJMcMDhsB6dteIQBpCFJb1rkoy8sz7xJlKCeOaip9ktVUta5gSRPlGocvLTAoNTmmW3JghApANKnS45ajlEJX0X1YD5mqDKNJ1lHUijD7BHR/B2d3SaJ6VXeUWP9YCsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VUZhdTulylQsusST1rtXTeuHClRUOnVVZaD/0BmX4Vk=; b=GHBzNyTPg2dqGyVxloaxaNcoGqT4t/8QlGEYklqcCoelZlNx3uHpk4gqKeDmLlGnS7I6m0J3fGdOEGbyTkHmYIXnYDrRFC+ILmZTYMqB/ue0bDLR2mCVr+b/4neJwhRw2LB523CKmEMIeZsKakrSo+4WplITMYdVnUZ4eFPZ5XKF572L4Al76YRwMrGr0/5k2dHOX33PMxjHx4tdn2scC0cXcKUNoFaO74Wxoi+jYE5+HL8EGeU7WuCEB5fAy+SYx3jGnSFZLjm7c2lMfAU02HHAY4+Ta3MlkysVFpz7aKGlNHfS6dcv+abGbW8ORYCaa79VbDk3EEawmrJxSaOptA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=dpdk.org smtp.mailfrom=nvidia.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VUZhdTulylQsusST1rtXTeuHClRUOnVVZaD/0BmX4Vk=; b=XAL/DdgQcqn71tuniSL24Z2ONJIA+amriQt7g0vMxPjkr9mHpgUDqTk5tfqHTh8dfAk0Lr1VG/FiZ/sMCz3NGBrO2DwqJ2cgSerum2Q9c7LQZj2wApA0MuZksQIxvqIYLu0sqWCWQckzbqWWGEbCIUDQzbAH6sUzUc93fUFxv35SUmIn+Gkb+JIrjcn8/KPBnoWO14UhDhr/4ZLXwaJUD0sSYH/RI2lIfAED7lkFCNMESONEk3EBMH1TJT1EaJV01DGHc5Dk8JZSkzALxewlc60UH2unr+5C1UYAvHYCiub34DWyPsg5oIPU7aiMjxMaXMPS2GB95Qzo1glsWF1sOg== Received: from CO2PR04CA0174.namprd04.prod.outlook.com (2603:10b6:104:4::28) by MN2PR12MB4568.namprd12.prod.outlook.com (2603:10b6:208:260::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.27; Wed, 2 Jun 2021 09:57:15 +0000 Received: from CO1NAM11FT037.eop-nam11.prod.protection.outlook.com (2603:10b6:104:4:cafe::78) by CO2PR04CA0174.outlook.office365.com (2603:10b6:104:4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.15 via Frontend Transport; Wed, 2 Jun 2021 09:57:15 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by CO1NAM11FT037.mail.protection.outlook.com (10.13.174.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4150.30 via Frontend Transport; Wed, 2 Jun 2021 09:57:15 +0000 Received: from [172.27.0.174] (172.20.187.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Jun 2021 09:57:11 +0000 To: Andrew Rybchenko , Ilya Maximets , Ivan Malov , 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> <11ed17c8-a3f4-3fcb-b11f-7c4ee903b991@oktetlabs.ru> From: Eli Britstein Message-ID: <4e53dced-2e88-3fde-f2b7-cb2e1368c1c8@nvidia.com> Date: Wed, 2 Jun 2021 12:57:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [172.20.187.6] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8a0015cb-18b2-4e61-7e90-08d925accd30 X-MS-TrafficTypeDiagnostic: MN2PR12MB4568: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 90wm9SEJK/HHZyq1d1ayxFwYFOp6r+GjYtQFJJV56nEEiUEw40b/CfV7JPbVuf1VFUZyQiU1HhPbflREYxhvuqc3jPgkgJrClTZck7qkMFc4nS5N8UlFEmObjF7vNy+2JN7mv3nPdzys7gCkR00N09H2fdX7MOXEXdL9PUkdMJmXP09jnczi260z/DSRZNsZYG0YUcCS9iJTNrwUjKggdVazKzysApR7MZiSMgJ/XwxoaGAXDuKrPZCOGEp1iydhlxpnwT1J5YKmybwB3IE74YRLEL6ygT/8c/Tsdle7+iD2tv6nCmKxIyDleQTK3uVnxhtaRHM86uUTw3VInEOL4rvkEXDsarldDQ9Nj0qYn3+JM+ZrIxOD5qrDDcrZ4p+Pqa9fxMfiG7zO/mFRUkTBjzKSU2phgQYLJVYrcIcWvOypP6aUtpRVhLDAVkM3fwnoqDfMQVSFt5AyQu6PyB62hZogn9hQIuASFSygn6tsEqGBE7EX6anSG4BsgQrb3PU3Csa85ybsx90kcGGEj/yNt7N4wLNgNleppBf6SShkjuuHCLPT1zXESuIkd0ROQl+froI3tHffrhqddWR+e6ZyAucAcP3dRHn3b5hW/rJaskSOnvr/ObqJMNeARU0YU4L5zeusg6JiyS62hECTjF8LjfrDeGqFd6v6kUEonBHXte22ylWS+HMxg08wv38IxaWQdX24cGOzA0hCKNaLs/BwLOMaVSgvkN3DxLZ8rKL3SH0P/BJ0YnRfLPP/f2r2REKY2YFHAlkpMjFYD8fPwbO1HfSIIFL3MA6nbd8xxQAMWl7lT/HgJJcI3aUzrq/8I1Th X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(46966006)(36840700001)(70586007)(8676002)(5660300002)(70206006)(336012)(478600001)(47076005)(6666004)(316002)(36860700001)(36906005)(16576012)(966005)(110136005)(8936002)(54906003)(2616005)(82740400003)(86362001)(26005)(53546011)(83380400001)(426003)(2906002)(16526019)(4326008)(7416002)(356005)(31696002)(36756003)(82310400003)(186003)(7636003)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2021 09:57:15.5606 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8a0015cb-18b2-4e61-7e90-08d925accd30 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT037.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4568 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/2021 5:53 PM, Andrew Rybchenko wrote: > External email: Use caution opening links or attachments > > > On 6/1/21 5:44 PM, Eli Britstein wrote: >> On 6/1/2021 5:35 PM, Andrew Rybchenko wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> 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. >> True. It is just the focus of this commit message is OVS. >>>> 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. >> This is the per-PMD responsibility. The API should not care. >>>> 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. >> Let's separate API from implementation. By API point of view, yes, the >> user may request it. Nothing wrong with it. >> >> From implementation point of view - yes, it might fail, but not for >> sure, even if on different NICs. Maybe the HW of a certain vendor has >> the capability to do it? >> >> We can't know, so I think the API should allow it. > Hold on. What should it allow? It is two opposite meanings: > 1. Direct traffic to DPDK ethdev port specified using ID to be > received and processed by the DPDK application. > 2. Direct traffic to an upstream port represented by the > DPDK port. > > The patch tries to address the ambiguity, misuse it in OvS > (from my point of view in accordance with the action > documentation), mis-implementation in a number of PMDs > (to work in OvS) and tries to sort it out with an explanation > why proposed direction is chosen. I realize that it could be > painful, but IMHO it is the best option here. Yes, it is a > point to discuss. > > To start with we should agree that that problem exists. > Second, we should agree on direction how to solve it. I agree. Suppose port 0 is the PF, and port 1 is a VF representor. IIUC, there are two options: 1. flow create 1 ingress transfer pattern eth / end action port_id id 0 upstream 1 / end 2. flow create 1 ingress transfer pattern eth / end action port_id id 0 upstream 0 / end [1] is the same behavior as today. [2] is a new behavior, the packet received by port 0 as if it arrived from the wire. Then, let's have more: 3. flow create 0 ingress transfer pattern eth / end action port_id id 1 upstream 1 / end 4. flow create 0 ingress transfer pattern eth / end action port_id id 1 upstream 0 / end if we have [2] and [4], the packet going from the VF will hit [2], then hit [4] and then [2] again in an endless loop? If this is your meaning, maybe what you are looking for is an action to change the in_port and continue processing? Please comment on the examples I gave or clarify the use case you are trying to do. Thanks, Eli > >>>>> 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.