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 E704FA0524; Wed, 2 Jun 2021 13:22:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6B4714069F; Wed, 2 Jun 2021 13:22:02 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2048.outbound.protection.outlook.com [40.107.236.48]) by mails.dpdk.org (Postfix) with ESMTP id D4D3D40689 for ; Wed, 2 Jun 2021 13:22:00 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FBnPzzoxM+k8Z+M4vPOetWW0ak72gVSzk5PZayRrZbYIj1GA5DGtELINFYC4dKhCER2XxyUtLAIhvzQ6sW8rfQ+jb2iEVrwraHq16JZ0uUOJ2GbEHTe1/WnDQi3c2ka5PXqtMzMOjVw99JmdSaFqPkJbRWNGXYCeNibE5CseKyNVd01Sx+6MvT2D1LCJf5MJ2gHIUKdg4DsWwZKVRn0DCGaaDvW/9zi0tK51dXVqj2RKIFWTveMkU91uJqnjk4ENeXLtSBdEc+FhWdU3zg2m6xmRzyZXPBerKPK2THpCLZz/0AC1sKUPJoMNKvSeV0mh4jo0j++ph48gtIh5e+BjMw== 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=WmoNnlXTCy/X1mfVXMfvQyKt907AVk9aYc1v52DsF3w=; b=DUQyVK+7c5mVdxXKONJBBKOZFbCIOQgS+3H9L4ERldRHPUpsGoUQDBiLTDTf/V9I6DSZJSkoM6hffNu3YygOU6okaiElgg2LBX8MzcHLObNYTX1CZJSKYkYoqkkzTDQQojHgv9s5FiEh4faPPWWQcpnpdGVD/aWYMMyr4kcKoUx+VQc78XIw+8dP9VeRmEzQzsvAfvcHSp9l43Mc6yT9K4HvPkgc6S7swf+p6ilqu98SDRdEkI25SdWWS4JWJB9u8E//u8ZzulmEPipRnjFp3dfneSROkXm8WM1TO8PWaw+0NDgj5lNQIEGgsOFAqxTgJk3R4qqW8b9n6qie5r1gJA== 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=WmoNnlXTCy/X1mfVXMfvQyKt907AVk9aYc1v52DsF3w=; b=n7CvUHhgaReKJ801a2bDY4l/gX5JnPamcXT3rsjWutEDWXNGK6MfCESvQVwB7ksI+G+xYDZfW5xeKTvV5+X7cZ+59soIotFv5rQKIZy7ZEczTbaI+eI6NccRtUpMVy5GMj4VxZf2lKMw7ovH5qleeAT3awEuCqbLqpFBi1NZfmg/zLHZBcfDczNnsDAqOTUa58yXhU+xT5/wej9KRBLS0KXJAK2H8wZZK0k0PUtQF/iVdCFKpX/9yBLN2Jbrsjp/0DC8zWsMG80RoRoYehF4/u++kwSp4UnS0rwSYVzdbAYZkQQ0Wr+HVKqDraNpbCgBsLxRztoBDm93pnj78zRiWw== Received: from BN6PR16CA0017.namprd16.prod.outlook.com (2603:10b6:404:f5::27) by SN1PR12MB2431.namprd12.prod.outlook.com (2603:10b6:802:27::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Wed, 2 Jun 2021 11:21:59 +0000 Received: from BN8NAM11FT037.eop-nam11.prod.protection.outlook.com (2603:10b6:404:f5:cafe::43) by BN6PR16CA0017.outlook.office365.com (2603:10b6:404:f5::27) 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 11:21:59 +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 BN8NAM11FT037.mail.protection.outlook.com (10.13.177.182) 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 11:21:58 +0000 Received: from [172.27.0.174] (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 2 Jun 2021 11:21:54 +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> <4e53dced-2e88-3fde-f2b7-cb2e1368c1c8@nvidia.com> <4447be7e-ce2a-a7a0-68e3-1de22a46cf80@oktetlabs.ru> From: Eli Britstein Message-ID: Date: Wed, 2 Jun 2021 14:21:51 +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: <4447be7e-ce2a-a7a0-68e3-1de22a46cf80@oktetlabs.ru> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [172.20.187.5] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a402826b-0963-4118-c227-08d925b8a31c X-MS-TrafficTypeDiagnostic: SN1PR12MB2431: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /r0LzfWbXFTNYacvwY8C20v30IaoJyNiC5nGna/0XZQUx1z3bASxXnsvFBCz7jrIl+OjSqYsIMyNNM8DP3F++A+snSel0/fEZoLc4xyPYLXpt+Be7/LvDeue34hp/7pyKyHLlrOO9dE82Q0e+U7sdcJodSebvWhukv4gNSplMaIFh0TqJW0Ydm19hnDxXhMpBTHys+ybKUTLArZsV68Idmk99F87TDCR62uewuwZGi1sHnpndcbwn6B8aYOMmOX3ci+P/jfIV/XhBB26RYTcgvcZQcVwRHlDl/5hglfL9gfl2WXW+nz3GPUqcMIpj0JxnumUcqDh0ohmaUMwCoNQuT/yU4f8odYZ4OxYeDVHvZsJ0phZryTA69bP7uFuFuisxmJq0UJCRC0LJqIYg+iuHyWJMXndocPGpy06vapmJF+/nQJSqh+p55DxHydG9WlIsBr7NwcXxnx2eB0WOP1+6HUVqUygQHLvtsPK5T46lP9FLVmMhiEJZ3ppiib0POGHV9aIQ+32Ap4QE5T9Qduz3Q3E3apMdMU2tpo+6VlngD/KHnWIjfDdIv5DlTRTrd92qAxg2ZsZWv/NFrqiY3kaThbJfv82xQZUoNtr0+hhGZql2rEeCnu+AnUmPEynh7skiMUjju6p5hdr5qLwV98oQZ3+hCXIPRguT5cTM2oakYXGIQkC0J9cp+tsbLPj95CfBaIreIaILbyFyvQO3D7gyE3JZGk/F7VpLMC5DTBAjrR0R71XCcOkGZeIJ5OBihciElGEQtiHfau8W4Jum24/I0Ilm4SfVpyu+BqW5C+tHCM6jAU0CcWz6HFhv5kxnBVJ 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)(346002)(396003)(39860400002)(136003)(376002)(36840700001)(46966006)(356005)(47076005)(82740400003)(7636003)(86362001)(966005)(2616005)(478600001)(82310400003)(31686004)(7416002)(8936002)(53546011)(70586007)(31696002)(16526019)(83380400001)(186003)(26005)(36756003)(36860700001)(36906005)(70206006)(6666004)(336012)(16576012)(8676002)(5660300002)(2906002)(54906003)(316002)(110136005)(4326008)(426003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2021 11:21:58.8098 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a402826b-0963-4118-c227-08d925b8a31c 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: BN8NAM11FT037.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB2431 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/2/2021 1:50 PM, Andrew Rybchenko wrote: > External email: Use caution opening links or attachments > > > On 6/2/21 12:57 PM, Eli Britstein wrote: >> 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? > As I understand PORT_ID is a fate action. So, no more lookups > are done. If the packet is loop back from applications, loop is > possible. I referred a HW loop, not SW. For example with JUMP action (also fate): flow create 0 group 0 ingress transfer pattern eth / end action jump group 1 / end flow create 0 group 1 ingress transfer pattern eth / end action jump group 0 / end > > In fact, it is a good question if "flow creare 0 ingress > transfer" or "flow create 1 ingress transfer" assume any > implicit filtering. I always thought that no. > i.e. if we have two network ports rule like > flow create 0 ingress transfer pattern eth / end \ > action port_id id 1 upstream 1 / end > will match packets incoming from any port into the switch > (network port 0, network port 1, VF or PF itself (???)). > The topic also requires explicit clarification. rte_flow is port based. It implicitly filters only packets for the provided port (0). Maybe need to clarify documentation and have a "no filtering" API if needed. > PF itself is really a hard question because of "ingress" > since traffic from PF is a traffic from DPDK application and > it is egress, not ingress. Ingress means the direction. Hit on packets otherwise provided to the SW by rte_eth_rx_burst(). Same goes for the PF. Packets by rte_eth_rx_burst are the ones arriving from the wire, so ingress is that direction and egress is from the app. > > I think that port ID used to created flow rule should not > apply any filtering in the case of transfer since we have > corresponding items to do it explicitly. If we do it implicitly > as well, we need some priorities and a way to avoid implicit > rules which makes things much harder to understand and > implement. If "upstream 0" means what I thought it means (comments?) maybe a better way to do it is expose another port for that, so there will be 2 "PF" ports - one as the wire representor and the other one as the "PF" (or clearer naming...). This would be a vendor decision, and there would be no need to change PORT_ID API. > >> 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.