Message ID | 20211019123722.3414694-1-dkozlyuk@nvidia.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AB654A0C4D; Tue, 19 Oct 2021 14:37:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 70845410FA; Tue, 19 Oct 2021 14:37:47 +0200 (CEST) Received: from AZHDRRW-EX01.nvidia.com (azhdrrw-ex01.nvidia.com [20.51.104.162]) by mails.dpdk.org (Postfix) with ESMTP id 5F874410F4 for <dev@dpdk.org>; Tue, 19 Oct 2021 14:37:46 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.106) by mxs.oss.nvidia.com (10.13.234.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.15; Tue, 19 Oct 2021 05:37:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NvpEBnWcql+ZWg5wKzg7pT1sLDe7zvAk/00O77UbrnCLAD8HTHic0WToVvfe3J64phyTUDP47dTZwj3fPBpwoi9yNkl2Yi5ge3+5pin0faS8fLJTvNWNOyKXAkbonLpUGZsYFzp0Bloz705TPnetabbcxEHGVBLnrrQQ0UrQGqEdlQWi9MV15QG/qZK1XzRR2Vyacv+QmLqCTQisQkZL9uKtZW1EphUM0+8ZWmfISeBIXgsHgE2wuSPnp4SxB5hpOakErjiRa08MbY84Y9d2t4X5SpjbnLQIF3HxndqdXaN1SyLUQiJtt6BL9dXCidnQAN4MlvhtLIP3+MBcwQJLaQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1PaCjdReOiyHVO/FqEy/f3N76vJKUeExxKgEpiwQ2VM=; b=c7veGQWz9ZicPcloUoqIzqtqDFrp1BoKruqJWOyj4vjdv5rf4BMm+0Pm5rcTzixWdLiZChGEtihAKkHzXcznfLbevcUWLVBkqgvcCYshX6OqEtOJ4Zege1igJNDKKBGL2klnILRvpXTbeM54H8yRdz28Zjz/mJScdf4m5yevO9sgClE3HXjqEdWLgHMsBmPsbRbAqLZhz7G1Va6L7JbqvB1Yrm8CfX6bSNGL+R5S6Bkdlh2cFwhy+tZ4DilLqxqVQrFXn1dCRA2/kPjuK3H+pvqE0zQUTXntVZ29BAun8tVJccKQrx1uxTbQ5CIbpr5YfaS0AztlIyTN/ydqNfBy+A== 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=quarantine sp=quarantine 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=1PaCjdReOiyHVO/FqEy/f3N76vJKUeExxKgEpiwQ2VM=; b=rkK+QNyVWeZEsEH77sOu5kZWclwe309T8PuuFQ+XMMuUaEfOIhrTxKIz/ridFcKSjB/7WS7rvGSTKOtE2XJahqxcqpI/I3cfyrl1UoLMDjU0gqUFGMJaqMv6x0Pl8QTHtB9YmAsRExmAwJiLj4tUtjBHWrv9sgEM56mKgcC6R+incZD4OTFK63lpcr+EfmiTCzmI47SugD7hlCy9NP+gx44mxcc02eb2pP8XAizawz3bIFSsDBDUMYKslHCd8NonlEuTxfIr6/PIyLgphElq+kSJfkFH9P+RJ3dDxIlwSyCany+/o8i1RVVlISzTeicPB1Ct5Y2uO1qbMy/JN6JGlg== Received: from DM5PR1101CA0021.namprd11.prod.outlook.com (2603:10b6:4:4c::31) by MN2PR12MB2943.namprd12.prod.outlook.com (2603:10b6:208:ad::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Tue, 19 Oct 2021 12:37:44 +0000 Received: from DM6NAM11FT013.eop-nam11.prod.protection.outlook.com (2603:10b6:4:4c:cafe::5b) by DM5PR1101CA0021.outlook.office365.com (2603:10b6:4:4c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.15 via Frontend Transport; Tue, 19 Oct 2021 12:37:44 +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 DM6NAM11FT013.mail.protection.outlook.com (10.13.173.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4608.15 via Frontend Transport; Tue, 19 Oct 2021 12:37:43 +0000 Received: from nvidia.com (172.20.187.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 19 Oct 2021 12:37:40 +0000 From: Dmitry Kozlyuk <dkozlyuk@oss.nvidia.com> To: <dev@dpdk.org> Date: Tue, 19 Oct 2021 15:37:16 +0300 Message-ID: <20211019123722.3414694-1-dkozlyuk@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211015161822.3099818-1-dkozlyuk@nvidia.com> References: <20211015161822.3099818-1-dkozlyuk@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.20.187.6] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 535d95cf-3851-41ee-c99b-08d992fd3f90 X-MS-TrafficTypeDiagnostic: MN2PR12MB2943: X-Microsoft-Antispam-PRVS: <MN2PR12MB2943B964179F1A3E5EE86448B9BD9@MN2PR12MB2943.namprd12.prod.outlook.com> X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nk/C398SOTTVaQ8W6MfLQwg6NcnWSAfzmSUnI2tf5Rym1ryFgaFKmM08rWVezU7cjAz9GzTeOxfB+9YmSUqRNIe3pvfh1P/Qr47Eyfv/q2ZEXqXJfoF9wE0RJMSRyKqGxoeNIezoHyXPx4/BNai+3xJUjBCxEo/vpU3FHiHhgOBdYAv83boMKCFpR8+7JzZBrLm+E3aHAPhwDgWHOvLg1KVOTzB2oMW8zTDnrjGgVZftcMw9rmOr6aHCrsL32LX4Gq3G8eD0qNevp5D2OtgpFnb5ChBxK8hnGwzYetuSXskrYfWOUEgv1OH6+3O4k9v4f1CoknhPSDO8ZkWHDKNaepglnUhgmF9MaXLy2AQ0uX8S3g4i5JxTL2WOBqY+srHw/nqPlUBO6CVdGtY2VZBIJdh7K/vmQtn4+s3oj/JSXZTkR7dVLqXZHysS3uXutk3SlwvB8k6zfx8hhZlQiwy+6PjRPerxM/1+/FGKh2iG3XmpI5GxhiNOfGmFjXkL9cIORhJ2b80mg0T/e4I3AcIejJ5a9yz/YGg7ClSRlvoKkN7aKwiR54WJostHkf3KXm7VCCVnAkRO0qlO+CRvJzBMNk83z5jq7dvHLSzePi2jNhPwC5/Jnztbw8AfOj7OpBsgXxA0/FY51A2y3vh3sPx7Z8Zdsqhv5jJhILXzleVovrBOkXmnaIkU0abSNHc8EzKpo5INlrkg7LKjOzUopubcHcnAfVm+fMVftHyOMs/msZTz3KBw90GqCpOVfPBAXjrgqF9trLEYS4fkyiizsnyIqdmcUS2qkIhxIpps71Fd9qc= 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)(36840700001)(46966006)(86362001)(5660300002)(36860700001)(316002)(26005)(47076005)(186003)(8676002)(6666004)(7696005)(70206006)(70586007)(508600001)(55016002)(966005)(356005)(6916009)(336012)(82310400003)(83380400001)(8936002)(16526019)(1076003)(36756003)(6286002)(7636003)(426003)(2616005)(36906005)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2021 12:37:43.5193 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 535d95cf-3851-41ee-c99b-08d992fd3f90 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: DM6NAM11FT013.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB2943 Subject: [dpdk-dev] [PATCH v3 0/6] Flow entites behavior on port restart X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
Flow entites behavior on port restart
|
|
Message
Dmitry Kozlyuk
Oct. 19, 2021, 12:37 p.m. UTC
It is unspecified whether flow rules and indirect actions are kept when a port is stopped, possibly reconfigured, and started again. Vendors approach the topic differently, e.g. mlx5 and i40e PMD disagree in whether flow rules can be kept, and mlx5 PMD would keep indirect actions. In the end, applications are greatly affected by whatever contract there is and need to know it. It is proposed to advertise capabilities of keeping flow rules and indirect actions (as a special case of shared object) using a combination of ethdev info and rte_flow calls. Then a bug is fixed in mlx5 PMD that prevented indirect RSS action from being kept, and the driver starts advertising the new capability. Prior discussions: 1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozlyuk@nvidia.com/ 2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozlyuk@nvidia.com/ v3: 1. Add a patch 3/6 to update all PMDs that implement rte_flow with an explicit reset of the new capability (Ferruh). 2. Change how the support of keeping particular kinds of flow rules is determined, improve wording (Andrew). 3. Do not require keeping rules and indirect actions across reconfiguration (Qi Zhang). 4. Improve wording (Ori). Dmitry Kozlyuk (6): ethdev: add capability to keep flow rules on restart ethdev: add capability to keep shared objects on restart net: advertise no support for keeping flow rules net/mlx5: discover max flow priority using DevX net/mlx5: create drop queue using DevX net/mlx5: preserve indirect actions on restart doc/guides/prog_guide/rte_flow.rst | 49 ++++ drivers/net/bnxt/bnxt_ethdev.c | 1 + drivers/net/bnxt/bnxt_reps.c | 1 + drivers/net/cnxk/cnxk_ethdev_ops.c | 1 + drivers/net/cxgbe/cxgbe_ethdev.c | 2 + drivers/net/dpaa2/dpaa2_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c | 2 + drivers/net/e1000/igb_ethdev.c | 1 + drivers/net/enic/enic_ethdev.c | 1 + drivers/net/failsafe/failsafe_ops.c | 1 + drivers/net/hinic/hinic_pmd_ethdev.c | 2 + drivers/net/hns3/hns3_ethdev.c | 1 + drivers/net/hns3/hns3_ethdev_vf.c | 1 + drivers/net/i40e/i40e_ethdev.c | 1 + drivers/net/i40e/i40e_vf_representor.c | 2 + drivers/net/iavf/iavf_ethdev.c | 1 + drivers/net/ice/ice_dcf_ethdev.c | 1 + drivers/net/igc/igc_ethdev.c | 1 + drivers/net/ipn3ke/ipn3ke_representor.c | 1 + drivers/net/mlx5/linux/mlx5_os.c | 5 - drivers/net/mlx5/mlx5_devx.c | 211 ++++++++++++++--- drivers/net/mlx5/mlx5_ethdev.c | 1 + drivers/net/mlx5/mlx5_flow.c | 292 ++++++++++++++++++++++-- drivers/net/mlx5/mlx5_flow.h | 6 + drivers/net/mlx5/mlx5_flow_dv.c | 103 +++++++++ drivers/net/mlx5/mlx5_flow_verbs.c | 77 +------ drivers/net/mlx5/mlx5_rx.h | 4 + drivers/net/mlx5/mlx5_rxq.c | 99 +++++++- drivers/net/mlx5/mlx5_trigger.c | 10 + drivers/net/mvpp2/mrvl_ethdev.c | 2 + drivers/net/octeontx2/otx2_ethdev_ops.c | 1 + drivers/net/qede/qede_ethdev.c | 1 + drivers/net/sfc/sfc_ethdev.c | 1 + drivers/net/softnic/rte_eth_softnic.c | 1 + drivers/net/tap/rte_eth_tap.c | 1 + drivers/net/txgbe/txgbe_ethdev.c | 1 + drivers/net/txgbe/txgbe_ethdev_vf.c | 1 + lib/ethdev/rte_ethdev.h | 10 + lib/ethdev/rte_flow.h | 1 + 39 files changed, 762 insertions(+), 137 deletions(-)
Comments
On 10/19/21 3:37 PM, Dmitry Kozlyuk wrote: > It is unspecified whether flow rules and indirect actions are kept > when a port is stopped, possibly reconfigured, and started again. > Vendors approach the topic differently, e.g. mlx5 and i40e PMD > disagree in whether flow rules can be kept, and mlx5 PMD would keep > indirect actions. In the end, applications are greatly affected > by whatever contract there is and need to know it. > > It is proposed to advertise capabilities of keeping flow rules > and indirect actions (as a special case of shared object) > using a combination of ethdev info and rte_flow calls. > Then a bug is fixed in mlx5 PMD that prevented indirect RSS action > from being kept, and the driver starts advertising the new capability. > > Prior discussions: > 1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozlyuk@nvidia.com/ > 2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozlyuk@nvidia.com/ Is there real usecase for keeping flow rules or indirect actions? Why does application want to restart port?
> -----Original Message----- > From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> > Sent: 20 октября 2021 г. 13:12 > To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/6] Flow entites behavior on port > restart > > External email: Use caution opening links or attachments > > > On 10/19/21 3:37 PM, Dmitry Kozlyuk wrote: > > It is unspecified whether flow rules and indirect actions are kept > > when a port is stopped, possibly reconfigured, and started again. > > Vendors approach the topic differently, e.g. mlx5 and i40e PMD > > disagree in whether flow rules can be kept, and mlx5 PMD would keep > > indirect actions. In the end, applications are greatly affected > > by whatever contract there is and need to know it. > > > > It is proposed to advertise capabilities of keeping flow rules > > and indirect actions (as a special case of shared object) > > using a combination of ethdev info and rte_flow calls. > > Then a bug is fixed in mlx5 PMD that prevented indirect RSS action > > from being kept, and the driver starts advertising the new capability. > > > > Prior discussions: > > 1) http://inbox.dpdk.org/dev/20210727073121.895620-1- > dkozlyuk@nvidia.com/ > > 2) http://inbox.dpdk.org/dev/20210901085516.3647814-1- > dkozlyuk@nvidia.com/ > > Is there real usecase for keeping flow rules or indirect > actions? > Why does application want to restart port? Sorry, I don't know of real use cases that would already use this feature. But on the other hand, there was no well-defined API to enable such apps. I can imagine apps adding queues (if their setup after the start is unsupported) and enabling offloads when available resources or traffic pattern changes, e.g. a DDoS attack starts and checksum calculation now wastes cycles on garbage. For indirect actions, as patch 2/6 mentions, persistent semantics are either natural (counters, meters) or just convenient. Working around with shifts for counters or tolerances for meters is possible of course, but it increases application state to manage. For rules, 1. It is worth noting that an app can create many of them before stopping a port, like a rule for each connection. Saving the application from tracking them in such case is a big advantage. If they cannot be restored before the port is started again, there will be a time gap when the traffic is flowing, but no rules process it. This alone could be covered by a distinct capability proposed earlier [1]. 2. However, nowadays, there are apps that create rules on their datapath. If rules are kept, such apps can reconfigure ports without either loosing the rules or having to track them very fast. As it is explained in the comments to patch 1/6 and 2/6, now that rules can exist when the port is not stated, it is logical that they need not be destroyed when the port is stopped. [1]: http://patchwork.dpdk.org/project/dpdk/patch/20211005171914.2936-1-xhavli56@stud.fit.vutbr.cz/