From patchwork Tue Oct 19 12:37:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Kozlyuk X-Patchwork-Id: 102221 X-Patchwork-Delegate: ferruh.yigit@amd.com Return-Path: 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 96C41A0C4D; Tue, 19 Oct 2021 14:37:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 769ED4119C; Tue, 19 Oct 2021 14:37:52 +0200 (CEST) Received: from AZHDRRW-EX02.NVIDIA.COM (azhdrrw-ex02.nvidia.com [20.64.145.131]) by mails.dpdk.org (Postfix) with ESMTP id EBD654119B for ; Tue, 19 Oct 2021 14:37:48 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.171) by mxs.oss.nvidia.com (10.13.234.37) 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:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FLja65HtoNKGPVmZyLPw4ZyEswvLToBGuol1mIIfPaEwUvbbEaYiVjaguyzlTgzunSmAYE+X1pPAmZt0FKugmsOFg+zZswcKqPf+NvY50grK42IHDJxJ7j5DBYOeYR+iQNVbF+pOmsF8+O2WZIAvzmfZSePE6FRLKUVyxiYSxZWkVPBkPkctc9aReMSEAB5QLltSyzuL16H7BiLrIRmeycXgT/m/X3ggX64x4fB8cqHrYiJMu5bsUTKRGYFOqd0sT/SbJj+Tax97zy7mFte5NAn8LlIhSJZMbrERNDkgl38Q0h5VdCCYV8d3BxwCoXDNIYVj1IxWGagixVJzb3wd9w== 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=k06OcFSgQ65q+HQN8mNMl4fCsb07qejD+ge0TvywRso=; b=NUirce4NxHiE77NXjLnkdoGYeMpifA3HIC0nc8qHZE0+gn7ZNxeKbgCtBjNpSi2R0WyUahDDukaz/8dlVGOCvw4N6fURUxHUccmIPfhoBm+sfywo51dR+Yc0Kh4EMv7bgt22j4JRxyHq5YNZQgLph0uNd646slOijhO4IfmSiUODB5b03iYeeISeS05jSsMXvMjS6Vc7F2W40o+rXcUnyQfDua7rAxpxainOlJy8aBq8LtKdUW7YAvXm3LMHgtKx8cXPoynCop+O99xUWXFmaqGNUbmTUsXUyBuwsmOw9wVPpNNtDOtnUhl2sD/gi4VZvVxR+9JbWRxwzhHt1yNDdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=intel.com 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=k06OcFSgQ65q+HQN8mNMl4fCsb07qejD+ge0TvywRso=; b=m3KFqpJtBDfcYvXN+Vk5xGgigf1EP4pSOJgC3wqBmbVChz9BCZeB/O9O+P8IZLiVkEoGo/eEyCRINolXnaeaBlz6HtQ/GsQNS5kZ4vJrv20DzRMl2qpEcb6Vntdauig/ACzgkvOHWtoiZfHXBMIvXECg0FM0+tS3n5VPrdzP6IhA6SwesLgnvr+lpk6x7waG+ihvSN8mkCDHcGg0GghcD0N3yvZXBrAgihzzv3N7qo+AR9C0xKkHsnOI1EASyStZbK71utCMUNaFH0ZyJVfquZT0AN9+4X96amEczQmNAU71rYqyO3d2/L5vpM6II/688eU0uGkhsp13BJKQ+mIzEA== Received: from DM5PR1101CA0013.namprd11.prod.outlook.com (2603:10b6:4:4c::23) by BN8PR12MB3041.namprd12.prod.outlook.com (2603:10b6:408:46::11) 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:46 +0000 Received: from DM6NAM11FT013.eop-nam11.prod.protection.outlook.com (2603:10b6:4:4c:cafe::1c) by DM5PR1101CA0013.outlook.office365.com (2603:10b6:4:4c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15 via Frontend Transport; Tue, 19 Oct 2021 12:37:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; intel.com; dkim=none (message not signed) header.d=none;intel.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 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:45 +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:41 +0000 From: Dmitry Kozlyuk To: CC: Qi Zhang , Ori Kam , "Thomas Monjalon" , Ferruh Yigit , Andrew Rybchenko Date: Tue, 19 Oct 2021 15:37:17 +0300 Message-ID: <20211019123722.3414694-2-dkozlyuk@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211019123722.3414694-1-dkozlyuk@nvidia.com> References: <20211015161822.3099818-1-dkozlyuk@nvidia.com> <20211019123722.3414694-1-dkozlyuk@nvidia.com> MIME-Version: 1.0 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: 40494a14-e0ec-4434-991f-08d992fd40e0 X-MS-TrafficTypeDiagnostic: BN8PR12MB3041: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Exchange-Transport-Forked: True X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iMG+KKoke/5XTrKKEcZu8YsDNxuA5zwbd3CV9N8boE6ayEkq8KA2w+FGiB1O2TkZAUpdUI2aoHZ/jdxMVkLzAYkyM9gP2/LbI9DKhucl7p8hgOxmwZ8dUm3unzIqUB1oBdCRtVHWUv/R+TL24kq7L/Nk5j4fZGCeFDtscV7F3lxc9agw4RIn0XpsftEmCcheyo40jzxbMxo75ImA2pVFUPICKlbN8E4HExtpPUDziZk6L/98crf99BD5AUPnGxwyWxDp8FDduFpTsa6V3PCEsq+yoJlCAorENlj40u9FCwcJ57T9OShJDHUrf7T1rGuEkrCDU6g+Zwj+s8AVpkEzQRByUng2jGCVxi4ISTs4eap8fu3gva2tHTNkVVehGBAlQXk+EAgW9es6HKcBLBFSoorOUhLoGy0miFtWKLBY2Na6Tn843CF0G204bxx5WGE1/xEBmDeERB6ODhHdlLmzHQkzcGNHWeWmmi3ptrZNJ0Ff0syMXeYeUkv6ZNZnhTI2stYJJEnQpELHxtu071m65r39wcN82IvHzLpD8ka6mMvLhwWxIjUZCGkl7kBcP5Ha3Ui6jU4QkQl+PkCqjlhXwG6XtlIhSTmrmnW7lEikQKnDDID1otAyGJU3agCXlpqojO0eqeOu3JAhFZOMRB3smIxTxsv0INdB+L+OlBs7vZQL9ic8HHA9KWZCxTdPjeIP5QW+7wFRr3I9ky7kejkOog== 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)(46966006)(36840700001)(316002)(2616005)(7636003)(6666004)(1076003)(6916009)(5660300002)(107886003)(82310400003)(8676002)(70586007)(36756003)(54906003)(86362001)(336012)(70206006)(36906005)(426003)(356005)(4326008)(8936002)(186003)(508600001)(7696005)(47076005)(16526019)(83380400001)(6286002)(55016002)(36860700001)(2906002)(26005); DIR:OUT; SFP:1101; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2021 12:37:45.7390 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 40494a14-e0ec-4434-991f-08d992fd40e0 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: BN8PR12MB3041 Subject: [dpdk-dev] [PATCH v3 1/6] ethdev: add capability to keep flow rules on restart 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" Previously, it was not specified what happens to the flow rules when the device is stopped, possibly reconfigured, then started. If flow rules were kept, it could be convenient for application developers, because they wouldn't need to save and restore them. However, due to the number of flows and possible creation rate it is impractical to save all flow rules in DPDK layer. This means that flow rules persistence really depends on whether PMD and HW can implement it efficiently. It can also be limited by the rule item and action types, and its attributes transfer bit (a combination of an item/action type and a value of the transfer bit is called a ruel feature). Add a device capability bit for PMDs that can keep at least some of the flow rules across restart. Without this capability behavior is still unspecified and it is declared that the application must flush the rules before stopping the device. Allow the application to test for persitence of rules using a particular feature by attempting to create a flow rule using that feature when the device is stopped and checking for the specific error. This is logical because if the PMD can to create the flow rule when the device is not started and use it after the start happens, it is natural that it can move its internal flow rule object to the same state when the device is stopped and restore the state when the device is started. Rule persistence across a reconfigurations is not required, because tracking all the rules and configuration-dependent resources they use may be infeasible. In case a PMD cannot keep the rules across reconfiguration, it is allowed just to report an error. Application must then flush the rules before attempting it. Signed-off-by: Dmitry Kozlyuk Acked-by: Ori Kam --- doc/guides/prog_guide/rte_flow.rst | 25 +++++++++++++++++++++++++ lib/ethdev/rte_ethdev.h | 7 +++++++ lib/ethdev/rte_flow.h | 1 + 3 files changed, 33 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 2b42d5ec8c..ff67b211e3 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -87,6 +87,31 @@ To avoid resource leaks on the PMD side, handles must be explicitly destroyed by the application before releasing associated resources such as queues and ports. +If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is not advertised, +rules cannot be created until the device is started for the first time +and cannot be kept when the device is stopped. +However, PMD also does not flush them automatically on stop, +so the application must call ``rte_flow_flush()`` or ``rte_flow_destroy()`` +before stopping the device to ensure no rules remain. + +If ``RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP`` is advertised, this means +the PMD can keep at least some rules across the device stop and start. +However, ``rte_eth_dev_configure()`` may fail if any rules remain, +so the application must flush them before attempting a reconfiguration. +Keeping may be unsupported for some types of rule items and actions, +as well as depending on the value of flow attributes transfer bit. +A combination of an item or action type and a value of the transfer bit +is called a rule feature. +To test if rules with a particular feature are kept, the application must try +to create a valid rule using this feature when the device is stopped +(after it has been configured or started previously). +If it fails with an error of type ``RTE_FLOW_ERROR_TYPE_STATE``, +rules using this feature are flushed when the device is stopped. +If it suceeds, such rules will be kept when the device is stopped, +provided they do not use other features that are not supported. +Rules that are created when the device is stopped, including the rules +created for the test, will be kept after the device is started. + The following sections cover: - **Attributes** (represented by ``struct rte_flow_attr``): properties of a diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index 6d80514ba7..a0b388bb25 100644 --- a/lib/ethdev/rte_ethdev.h +++ b/lib/ethdev/rte_ethdev.h @@ -90,6 +90,11 @@ * - flow director filtering mode (but not filtering rules) * - NIC queue statistics mappings * + * The following configuration may be retained or not + * depending on the device capabilities: + * + * - flow rules + * * Any other configuration will not be stored and will need to be re-entered * before a call to rte_eth_dev_start(). * @@ -1445,6 +1450,8 @@ struct rte_eth_conf { #define RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP 0x00000001 /** Device supports Tx queue setup after device started. */ #define RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002 +/** Device supports keeping flow rules across restart. */ +#define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP 0x00000004 /**@}*/ /* diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index a89945061a..aa0182d021 100644 --- a/lib/ethdev/rte_flow.h +++ b/lib/ethdev/rte_flow.h @@ -3344,6 +3344,7 @@ enum rte_flow_error_type { RTE_FLOW_ERROR_TYPE_ACTION_NUM, /**< Number of actions. */ RTE_FLOW_ERROR_TYPE_ACTION_CONF, /**< Action configuration. */ RTE_FLOW_ERROR_TYPE_ACTION, /**< Specific action. */ + RTE_FLOW_ERROR_TYPE_STATE, /**< Current device state. */ }; /**