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 EBEBFA0524; Tue, 1 Jun 2021 16:44:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 69AE440689; Tue, 1 Jun 2021 16:44:46 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2066.outbound.protection.outlook.com [40.107.236.66]) by mails.dpdk.org (Postfix) with ESMTP id 00F4340041 for ; Tue, 1 Jun 2021 16:44:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jawqQGE3iQrfeUcWiHvVhnKLWbxbbYujdVesWXTERuRAUvR/49ywGhoMTkIv5jH5NKdFCHG89sroChAVm2Pcv9WZGomKlhq0tmdtZmcb88wUUIQgzHIj7xh3AMiGukP9cig4n/SroB02jNggNYfunnqv+6iUF5rf3g4ly0Frat7vNChQ9n+9hHxaoDQGPnkx41MNbzXn+GG5+5P//phtxsEg7+/ulObZDvfXAOLpt/t3ZqZIhbBmd1HNzBevwakeLAkwJOvvzduUQ3uwMS8+YZcAbysoC+iMdjgwTToaXbxY1I+ZHArJehrBJEeLZs3ASlHeoma9akqcx67rhnGHIQ== 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=r3SyBQh93ae3+ysIUO/68gpzB42uVLNL/7EZeImLxUM=; b=a4fe+PzOsWp20yEjoen8KDwug9M3bTvXBEsq+qXt8WND9FfK3cMajcxZnnzXUVp9pcXPtgl4lyBS3y7cUKnd/VN6hahHa+665/FV6fxi2VtRQ8JWsRF0BS9w87wfyYHbrT1b+zi3SCxtMv1Fs8mhA8eXRPWNHx4HqPrw/VHQhdkHvV5Jr3CJHyRNIciVe5ch/c/ABqZ7ctQFTVbMSHO0VwXY3U0LazezCiyAPkcIQpmjpZK8TgscsO5YgkOgACfD7YyB34ZRq6dhgyPssJX/wZEAaNG54wlOHlcz5EvQ5w6ZVEZhR680HLBvx89Mj7qvh9wcnHmpbPlcr02Twnw8BA== 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=r3SyBQh93ae3+ysIUO/68gpzB42uVLNL/7EZeImLxUM=; b=VKYayzdI8chEp/xFmso8ncRJGJq02bRuTwDVV2+Z3i0y/zDgg13tTz2gQcNw240XiXgUtSYa0T/y2FnIhviYk9vSMUzlKSXHqJZWZfXSfvhoMDYSLtxWy5x4KzraJrNwDIstORUvNX3C4PUM2ypx2imgW+qwbfv3r+XhkoQkmivAyuw7p2mURz2swzH/wMZS/wgUYzYHm9/p8wErWcVWyUYc+a2JFxWVUynV2SMKi2+Rt8zggsw45MfZB9pkJikRO9QJB7L+CgcAR/wgDE7xV4Zl5rl7VQxbvxosuj2gweuMO9xm6PPtYkoapieHgwo6W0zcHKojnLtF5a/8dHyICA== Received: from DS7PR03CA0051.namprd03.prod.outlook.com (2603:10b6:5:3b5::26) by SN6PR12MB2799.namprd12.prod.outlook.com (2603:10b6:805:77::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20; Tue, 1 Jun 2021 14:44:43 +0000 Received: from DM6NAM11FT067.eop-nam11.prod.protection.outlook.com (2603:10b6:5:3b5:cafe::ae) by DS7PR03CA0051.outlook.office365.com (2603:10b6:5:3b5::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.20 via Frontend Transport; Tue, 1 Jun 2021 14:44:43 +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 DM6NAM11FT067.mail.protection.outlook.com (10.13.172.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4150.30 via Frontend Transport; Tue, 1 Jun 2021 14:44:42 +0000 Received: from [172.27.0.89] (172.20.187.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Jun 2021 14:44:38 +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: Date: Tue, 1 Jun 2021 17:44:35 +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: <11ed17c8-a3f4-3fcb-b11f-7c4ee903b991@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.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: 29bee4f9-19a1-40ff-f2db-08d9250bcaef X-MS-TrafficTypeDiagnostic: SN6PR12MB2799: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sJZ+WzQPil4vrIBMoSES9YBLNrNxbAz4ybe2gUCz+lWDhrCsoD2NdX/Ry3xLn6urzyqqYRzs09H+p3weU6nkIOx3AbTcdjTlPRU7y51xxL//LJAd/PLvpwvPRFn7Xlap2ExOos2JmTaMV2xQ83BoZrC2x/F2oK1IWNYH/hFvbcxSyIDs771aTqSOTwWd99gztv3XariIEj2P3gi2+XbN1+/SR9lmkGsPaDEQGC+YLepJZgXwprYGuhVUSKY30G6hSCzJAq+2dyYrsGqCi2E9roUHFke2iQvXR10GzTOGFWOIW6NReUISbrUNuosA8eDyDqEQ6yuOjBN5yDJrlxLvuvNvOy9OF7hcsUEu5X1gIV10rPvb7zshjCC67g1rChIIw0+dg8uF+e/rDPZIS+2YRTxTcn98kArSYC43gOK3YTk/U3rBLIGPqhfEFuXiqT9sq2qdNv3vtqf1KiJu4VMbokbeTKvGFElnXgU+CiEAQaoU/uHvMXqZd8ifXBo7ORvXP0SfakCIwYjFqq3kUz9P1NVf4dDP1VP2RRVsMV/YA85amsFVbVpfl7L213zLEb4gQ816f63h6dFNZ9Ti/FNfVN0je9eV+D7k9aIL3hoyKvux29kA8DIKIAaFcRzO4k+2YcABsqNiHOkSVserzmH2aNuCmHgdqkgys2i0o1RzzTHQC1HHcGnF8PeszkIosGoycZAubKyAWwHwWiH0Jzr1R3UkMdyKRWbOOG6eXKpLXnBBaa64/OKfXcLIH18PHKKHti1QbUmxcZe6rR1bTUzUDwJjH+xcsuDhCaFYj9ebrISdti7JLgsP9TBLBnomnlBk 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)(39860400002)(346002)(376002)(136003)(396003)(36840700001)(46966006)(53546011)(316002)(16576012)(110136005)(54906003)(36906005)(31686004)(8676002)(2616005)(7416002)(8936002)(2906002)(26005)(6666004)(7636003)(36860700001)(47076005)(82740400003)(36756003)(86362001)(4326008)(356005)(336012)(16526019)(186003)(426003)(31696002)(83380400001)(5660300002)(82310400003)(70206006)(70586007)(478600001)(966005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2021 14:44:42.8127 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 29bee4f9-19a1-40ff-f2db-08d9250bcaef 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: DM6NAM11FT067.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2799 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: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. > >>> 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.