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 5901DA0524; Tue, 1 Jun 2021 15:25:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D371640689; Tue, 1 Jun 2021 15:25:16 +0200 (CEST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2082.outbound.protection.outlook.com [40.107.92.82]) by mails.dpdk.org (Postfix) with ESMTP id 75EF240041 for ; Tue, 1 Jun 2021 15:25:15 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IOTwRPCFOiM/bx8vKjLXZbkMtG9ik/hk78YbVNMmfojl3ADgq6E2b5h5RJ/xNpKzj8hAyxqIaGJ8X8ebEpWsO6PbYElgpvDxbhlhS4fLAqu9ivSJfy5uhYji1KMWNVrfgQCH0UqlxYDLu9iatAeAf784yVABosDTiVfKyMLwbBLZyMy2Dh5aJ+9/fu7Rix1fRyuRpXGTBWuMasgUvatp+N4I1WqpMxohBKf0AT33Eyz3h7RkGBGcDeVaq02gBhk5ymcC4Q2OZgj/ZyYTKIEniBML1TSjDhK28pW/m/dLAUh3/lDJmUO9ZjAlGBTtVJ8GCRpNXbDrMSmMKzJYpr+yig== 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=RV/ASp657Df3ThXzAN2//M+BI5M0nhBLA9Nj/LPASvQ=; b=LtUF2fhRnJyeJF1To3aLCIfZCciZ2dyEZ1PyRk6ghC7czLy1ptDmiH28K0QOD5NYN3hP4CZG3cldRDr3FysC0Tk/dZKHXV6ooAoDbqDJ6iZcGslV3Ms2vQ58Ir0K/nItRx3ogLnm1XCU5tkS2J2KH0XHjf3CiM4aCCcBuMsWXZWDzqHKy6XbQRiw+uve+HkkKqXu+WEIJ98RxsO7+jcm6HpY2QkG4n24nsfnEl2WpkFvVAcDoscxN+YA7JYtsEMmfbwaZ9GxkT1DXG0JTQ3GVofXKARrpE/ymCM0hWWyLnjFoLafRhfkiBah1hpWbvYGGZfG1hoCod65cd8Cz5iy8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=marvell.com 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=RV/ASp657Df3ThXzAN2//M+BI5M0nhBLA9Nj/LPASvQ=; b=Rz5doIduLa9NHmO2fcqbfXsW6VZfQs/S6Qnvdlv4pV8PjmmEb4GdVnU6fsowmNekoyPRNQ2G8BTu/jIrERRJK1hRuhK7bTtBFeyiNTWpyRFDaIMw/bRBudt3YVDwbSO4QUkFKblWF7/bcNSYqV0pZLuV4fghRUQL6t55WbmNoP+N0FvsiOj7ecn5VVN8sxg90OLK7nbPtMIcYRv9APMs7zVEQzMdfjOaQCtU5D9zO6QDTLDbEMEVgwL2KxzNBpsGP9JcjbXsJX3bken/UcBXm4gEgV0oDnKgRqMzV3HhCW1RU8BHldzgKpN4nlPOapmBS8Gitvbw3ogzaifyLbmeWw== Received: from DM6PR07CA0065.namprd07.prod.outlook.com (2603:10b6:5:74::42) by SJ0PR12MB5422.namprd12.prod.outlook.com (2603:10b6:a03:3ac::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.24; Tue, 1 Jun 2021 13:25:14 +0000 Received: from DM6NAM11FT020.eop-nam11.prod.protection.outlook.com (2603:10b6:5:74:cafe::5d) by DM6PR07CA0065.outlook.office365.com (2603:10b6:5:74::42) 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 13:25:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; marvell.com; dkim=none (message not signed) header.d=none;marvell.com; 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 DM6NAM11FT020.mail.protection.outlook.com (10.13.172.224) 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 13:25:13 +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 13:25:05 +0000 To: Ilya Maximets , Ivan Malov , CC: Smadar Fuks , Hyong Youb Kim , Kishore Padmanabha , Ori Kam , Ajit Khaparde , Jerin Jacob , John Daley , Thomas Monjalon , Ferruh Yigit , "Andrew Rybchenko" References: <20210601111420.5549-1-ivan.malov@oktetlabs.ru> <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> From: Eli Britstein Message-ID: <9ed06b56-26e1-5812-e357-81147e699b3b@nvidia.com> Date: Tue, 1 Jun 2021 16:24:58 +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: <8c4f559e-3430-e2d5-1199-f1d4f4a8546d@ovn.org> 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: f981e60d-c0f4-4386-2e47-08d92500b06d X-MS-TrafficTypeDiagnostic: SJ0PR12MB5422: 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: bnhoZRorI0PLohWP/zk6/pN8bUkQueFH2Aid1wztir5eFodnVngg7o1ludiuCSYxxrJGZ9DoJ4Da9nT0yZ9qf7OxUcJHk65qMwGeezy14w4Gr2ZUu9s0LmN1D2XOhXDyYVgEHmt/kUo0e93FKIE1CVvU07jV+tgAa3ViDhcAEmbt2khk3vvkzdYHsM6lym+wDyG9bBj1C4FKP3y9pqD1sUVQpii75AWsDT+q23c9yKeaJ8D3YcJAnMB7W6rUKr5S2q/Vxv628MEgMTL7nVh4nceDURlAkiI2wygAhTOvJc8hBzgU18l1xVugQVWjkoPE56EuCGnLp9GjZJfMH9vkyMwfh1W6AKR5UHhBneDQxDpyZtNlus4E9QZVm4yvG/qd18xztdjfHL1HtepS/0KXH+hDj81g/phCJ6ZBPfilx6g1bWBLDYM7TOHEIYYmb9ZJfyNd/0lMdWDHcDsxg9kOhYlstiywQYjlvvw9seNf+2ZZkLn3cYATXk4Izvw8n/DoRUAVdNEEACxEyVCLbAIci5xv7BGuKo1CLrypOCfTK0ot4Y3UjeBmsfSHPXpRcpQNEB9354fq5Kkmnsei/orf9SNUeFAJz/eiqTBqsrIAkGUkatQfMC5Uyz4ihZMDLHvyvoMvzu8m1VKAlMin7AIe/uxxTrptv0JFJAOU4FU2snIm80XeuSQCPE3gyutzApISHvYc7BO0zUIAGgub6+SunxJyvP9n+8BRlAtJhDup4lwxqeagV+qr6SHiwQhFmpRCnVGHnsmQvayV8vr7WLCknoA7TkppE89SaRyH5wAUnD6oMNyFQDWxrvXo7QFuboDr 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)(136003)(396003)(39860400002)(346002)(376002)(36840700001)(46966006)(82740400003)(8936002)(5660300002)(966005)(36756003)(82310400003)(6666004)(110136005)(86362001)(4326008)(356005)(47076005)(83380400001)(54906003)(26005)(2616005)(36906005)(31686004)(316002)(31696002)(186003)(16576012)(16526019)(53546011)(36860700001)(7636003)(70206006)(8676002)(478600001)(2906002)(426003)(336012)(7416002)(70586007)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2021 13:25:13.8729 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f981e60d-c0f4-4386-2e47-08d92500b06d 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: DM6NAM11FT020.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB5422 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 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. For the PF, when in switchdev mode, it is the "uplink representor", so it is also a representor. 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. > 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.