From patchwork Tue Oct 5 00:52:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Kozlyuk X-Patchwork-Id: 100477 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 70980A0C41; Tue, 5 Oct 2021 02:52:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 423F841278; Tue, 5 Oct 2021 02:52:38 +0200 (CEST) Received: from AZHDRRW-EX01.nvidia.com (azhdrrw-ex01.nvidia.com [20.51.104.162]) by mails.dpdk.org (Postfix) with ESMTP id 69A1041270 for ; Tue, 5 Oct 2021 02:52:37 +0200 (CEST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.174) 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; Mon, 4 Oct 2021 17:52:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d8u+rbWejLkUKvlFSXgMi+Uv77DqMcTh38otTQbDdmNOhauS2awP6igECtACDeZzJd/1dneVYMVioH+UV/uFR6FKoVqX5oPkRF8VXNf6HrWhJp9UNJKToxa1bSamSeiMEadbFSydz5Rwaz0mkEhBquPWjahCJmIDUZLmhV7lNmVzMiyPKTEbBN/oKkTFxu7d6qVlumZNr9W7YmyhVclqrix5itvFhvTzOR5C3iOhOiVS3mNRPLtvtw2OA5HDXrqNpWf8dKxyClmrJl6heHDeoE/GFxrG+I4r21vlkNw10aZOdV+k+DXLJw2GOqGbilRLrCOBoCCnfl6zsc+iaKZS2Q== 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=dnnRFPcWK5hBE4P7PcE0jyfchbiq0bGH3Ma8OVR5qZs=; b=On2LXCdWrtt2PXO2YVjDS6sPMHHqwxxzf8r7ZsqP3gRZZhjG17Nspsx4f0VNKkBF9FQsPsBkURU38stx1CoDTadRqcgN7qs8nsdXLLw41uTCDjrn1sEVL6FMvtMxT/wP+Ku9f1eb80BER22D8Xwu6LW7obkpknwbm7IPQoPL2+/N5emd/4kzERNuMReHtnkWCGCNCOdiclFDd6ctQz5aO3vXUTQUZyf2hasOqf8P5lJCplMupxSxtckRaLGsaNSMWjd4J1qOk6ysxczVIQtcmU4SGYnzW4JepEliSakktIVXwDokEkA2sjO/x1i1rTa+MzKw2ngUR5SzRHKzyKqNXg== 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=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=dnnRFPcWK5hBE4P7PcE0jyfchbiq0bGH3Ma8OVR5qZs=; b=sH8hd329aFHT4E0wu/47ZECFlXvx8qI7ILlU90EvkbHUK18bkeWTBO+l8DIx15YFMgfShFZX/Zxo33PNHCDYPkza39vTPbezDZh3VHsjVDtug2BTsHlMtLurkKSHzX5fKyPTbfIAzMWLyzSWQJaDSzLfGO0FJbojHu2MVNGA/bl5jtKMnl4UcCTFqZkHQkeH+0CuViyM5CxXaFWDcja+dWV9bre3+FAymJ5lx58AFVuwPecBdvCFqox6LXaFL3QyfDBWoAnhrEJs1sC7tYvxSF4wdaqW+QDdFhJ5SyELMuFA9w4dQ1VXRGcRDgIC/bxe8bvIuICb8s1F9xUeu6w3Zw== Received: from BN0PR02CA0013.namprd02.prod.outlook.com (2603:10b6:408:e4::18) by BL0PR12MB4867.namprd12.prod.outlook.com (2603:10b6:208:17e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Tue, 5 Oct 2021 00:52:35 +0000 Received: from BN8NAM11FT035.eop-nam11.prod.protection.outlook.com (2603:10b6:408:e4:cafe::fa) by BN0PR02CA0013.outlook.office365.com (2603:10b6:408:e4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14 via Frontend Transport; Tue, 5 Oct 2021 00:52:35 +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 BN8NAM11FT035.mail.protection.outlook.com (10.13.177.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4566.14 via Frontend Transport; Tue, 5 Oct 2021 00:52:35 +0000 Received: from nvidia.com (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 5 Oct 2021 00:52:33 +0000 From: To: CC: Dmitry Kozlyuk , Ori Kam , "Thomas Monjalon" , Ferruh Yigit , Andrew Rybchenko Date: Tue, 5 Oct 2021 03:52:13 +0300 Message-ID: <20211005005216.2427489-3-dkozlyuk@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211005005216.2427489-1-dkozlyuk@nvidia.com> References: <20211005005216.2427489-1-dkozlyuk@nvidia.com> MIME-Version: 1.0 X-Originating-IP: [172.20.187.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa314c9f-cb3e-42a3-9c61-08d9879a6bbd X-MS-TrafficTypeDiagnostic: BL0PR12MB4867: 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:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rdSgLb99AUCB0Sxqqxk8Ko3mGQLixzD31gRpjzEELPqwJk5rFsHzdxxYylVGxHVzZD7cahNljwmccQ/fm7rNRLh+9k9uGSDf2tjrGzlAf8w041NpULGxSQxBDBNQ8bM9TLWRtuJSWoLG/6tGPEs6HJGGr+YW08Mvz4jL5sKqqJmQDMKgTrFab1wSczQAR35x4nIy06k8wpAJLf7x4uCPIV2Z4OTE3aJCqRLEkNlFqhzQPQhQHbztGMKsXh5TpVUxIxtNtBmtTSFACmG89PLjtC903O5D7DC8ugNo3ZdAn6CqpTcnnYh9O9xxI5SUVRSZWJi7yqNLflC2mdcQrNBnAw8q+a91EkSJn0NWE8lBG2mFKFS3wz6642i9SfpIFDQfGEzFcvr9uKGn/20RM/ZyqQlKyJO9XGRMBV5GEcl4ZKvd62ydFlQp4JUcV4v5I4yD8Jgxv+xxLD3bE+GPif9s8tkRPN4L2L3YkPCp3Ir5OGyMr68NUT2mBwz/IA0OdmFhHNzv2qu/Yr7WtPgdSXUPM7aDvwQQmtsZEraYpRPvmWP/WmrJo0PF/GAdEIp3H/Po+NJIiUB7x4ArM2bVttIcrFURP3CJ0n57oyiKjfPsCSwAscJHF8VYMzmsmE7wV0VA5jXqh7tfRdckbzmbUwaAci++KcnuKcw8TGLFQy/e0OhubiIY0Czs/7CbvKIx2StFxqkLrhvvFYp96ZWJzrA2vA== 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)(5660300002)(7636003)(70206006)(36906005)(47076005)(8676002)(54906003)(70586007)(7696005)(26005)(508600001)(36860700001)(55016002)(16526019)(36756003)(356005)(186003)(107886003)(336012)(83380400001)(8936002)(6916009)(316002)(4326008)(2876002)(86362001)(6666004)(82310400003)(2616005)(426003)(1076003)(6286002)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2021 00:52:35.0198 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fa314c9f-cb3e-42a3-9c61-08d9879a6bbd 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: BN8NAM11FT035.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB4867 Subject: [dpdk-dev] [PATCH 2/5] ethdev: add capability to keep shared objects 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" From: Dmitry Kozlyuk rte_flow_action_handle_create() did not mention what happens with an indirect action when a device is stopped, possibly reconfigured, and started again. It is natural for some indirect actions to be persistent, like counters and meters; keeping others just saves application time and complexity. However, not all PMDs can support it. It is proposed to add a device capability to indicate if indirect actions are kept across the above sequence or implicitly destroyed. In the future, indirect actions may not be the only type of objects shared between flow rules. The capability bit intends to cover all possible types of such objects, hence its name. It may happen that in the future a PMD acquires support for a type of shared objects that it cannot keep across a restart. It is undesirable to stop advertising the capability so that applications that don't use objects of the problematic type can still take advantage of it. This is why PMDs are allowed to keep only a subset of shared objects provided that the vendor mandatorily documents it. If the device is being reconfigured in a way that is incompatible with an existing shared objects, PMD is required to report an error. This is mandatory, because flow API does not supply users with capabilities, so this is the only way for a user to learn that configuration is invalid. For example, if queue count changes and RSS indirect action specifies queues that are going away, the user must update the action before removing the queues or remove the action and all flow rules that were using it. Signed-off-by: Dmitry Kozlyuk Acked-by: Ori Kam --- doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++ lib/ethdev/rte_ethdev.h | 6 ++++++ 2 files changed, 18 insertions(+) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 0a03097a7c..4597853bff 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -2794,6 +2794,18 @@ updated depend on the type of the ``action`` and different for every type. The indirect action specified data (e.g. counter) can be queried by ``rte_flow_action_handle_query()``. +By default indirect actions are destroyed when the device is stopped. +If the device advertises ``RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP``, +indirect actions persist across the device stop and start with possible +reconfiguration in between. Some configuration changes may be incompatible +with existing indirect actions, in this case ``rte_eth_dev_configure()`` and/or +``rte_eth_rx/tx_queue_setup()`` will fail. At this point PMD developers +are encouraged to log errors identical to the ones that would be emitted by +``rte_flow_action_handle_create()`` if the new configuration was active. +Even if this capability is advertised, there may be kinds of indirect actions +that the device cannot keep. They are implicitly destroyed at device stop. +PMD developers must document such kinds of actions if applicable. + .. _table_rte_flow_action_handle: .. table:: INDIRECT diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index d24de5e8fa..3d9a42672f 100644 --- a/lib/ethdev/rte_ethdev.h +++ b/lib/ethdev/rte_ethdev.h @@ -1480,6 +1480,12 @@ struct rte_eth_conf { #define RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002 /** Device keeps flow rules across restart and reconfiguration. */ #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP 0x00000004 +/** + * Device keeps objects that are shared between flow rules, + * e.g. indirect actions, across restart and reconfiguration. + * For a specific PMD this may not be applicable to certain action types. + */ +#define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP 0x00000008 /**@}*/ /*