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 E6150A00C5; Fri, 4 Nov 2022 11:45:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7AF6E42D10; Fri, 4 Nov 2022 11:45:11 +0100 (CET) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on2045.outbound.protection.outlook.com [40.107.95.45]) by mails.dpdk.org (Postfix) with ESMTP id 0B27942D0E for ; Fri, 4 Nov 2022 11:45:10 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P+QSgtCiNr+SGcZK/t48oiywp+0rOOy719WVgP1w3hTMBHVaL47ZsZ/2jtlSYmEFm8JRhI2HI2Mmd3esUlOD760+OkAXKT2l6R91kbHbOhCaLmcDruP0B7BmzbqPlo6qK+vbjbG1/0RS+3k2cNp5VLW7s+N2ByI4EFGfSqaE6Z4patWsh73EKtj2lKEBiMip4rEW8+8+7++ATHEP9CMan0ShtNamtwWwY2UywfXTi6AO79p0rlvrCrIzW/c1vf0mPw2cX1LeD5iwuaNd1Z9asr/D0FRdW3L3TrvGX35uCf/PmZT3ok4wczgxiTt+4brRif4ki0zvyq1U0ZNlXFuUrA== 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=k+geMKVRz0D5VV3EIamc7L93sTmWqKS6sPy4rJEcUc0=; b=nHl+DwIzn8hmIO9jY+sSS0rmKd/ctZmu2VSaqEDDvpy4a8+uw9CLZEUyzgEptBQVvutNEKpk7US4zg2mAzT3gbamdVJqjpYO3gT+Wj1u/uhRyxS0hcpBK217Tdhp3kwA7oROJAWoo8Pz+CdFmXt+dGJymswAH3OMVOrSuRtQE+azLOP0R0z+ZElz5QWYyf05HqYDDeplV3EjgdVVVCqfnjBp6Za8kmBjiIQe0IwvpPtB3CT7IHWMrShGz5nnI9Ru1o+N3JdLZUxNWWsCws2bmN2YqQy1dg6ej0CVoUioEHrxGBaFXnT+yuVSqjVjTsoXQUau0ciOpjt1QvhJR9PHhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=monjalon.net smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject 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=k+geMKVRz0D5VV3EIamc7L93sTmWqKS6sPy4rJEcUc0=; b=atsEiL6bn9ERXB2639XmAuY2k/odRz+OuuLd+bfLVYZZsRB7ns3QwioUnbaDMVzIbWLp+Cv8SdPDg4O8zk6E8dDn+jmwPe3XzdhsA8gb2Z7KP70Gwh22fO8uFmA3M2+7Gxb3KoIiMwatLO2e4sVz659k+wQOLDs0X6VWMgMrGxggtnG9zV2QoUdw6aTaE45mGSrhuUEfcQlZHhOMrlJdhVSklDgZanI4gQ60ug1qw1COM/PsKkleIk6Nocsr0UpoUNPTWc5J+aNRByh6DNhNWpwyBHbcvi7MWAcejN5Y161gmgYPnpLZtpgu/IucxTFNNrNvhLW8GR9KCMOqZODvEQ== Received: from BN8PR03CA0006.namprd03.prod.outlook.com (2603:10b6:408:94::19) by MW3PR12MB4508.namprd12.prod.outlook.com (2603:10b6:303:5b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22; Fri, 4 Nov 2022 10:45:07 +0000 Received: from BN8NAM11FT060.eop-nam11.prod.protection.outlook.com (2603:10b6:408:94:cafe::2a) by BN8PR03CA0006.outlook.office365.com (2603:10b6:408:94::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.22 via Frontend Transport; Fri, 4 Nov 2022 10:45:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by BN8NAM11FT060.mail.protection.outlook.com (10.13.177.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.20 via Frontend Transport; Fri, 4 Nov 2022 10:45:06 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.26; Fri, 4 Nov 2022 03:44:56 -0700 Received: from nvidia.com (10.126.231.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Fri, 4 Nov 2022 03:44:54 -0700 From: Rongwei Liu To: , , , , Aman Singh , Yuying Zhang , Ferruh Yigit , "Andrew Rybchenko" CC: , Subject: [PATCH v4] ethdev: add special flags when creating async transfer table Date: Fri, 4 Nov 2022 12:44:39 +0200 Message-ID: <20221104104439.230147-1-rongweil@nvidia.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.126.231.35] X-ClientProxiedBy: rnnvmail203.nvidia.com (10.129.68.9) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM11FT060:EE_|MW3PR12MB4508:EE_ X-MS-Office365-Filtering-Correlation-Id: 227ca4d6-3f98-40fd-356c-08dabe51a382 X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eQLfj1noDbfAbwhS0LIP7t3W4p8C5caYoXBhusQnURdgIfIwmaal+P/NDUDjzg73OVXc9BtZD0Cm13XMqpOsZAXohtpMwpOUMMPgyM8VdZ/NLMA8pqH4wWj47XbHaALzgl2wE8XuaZIBrbGh1XaQopAFq7WqtVgrkSd40XTL26b3uF6VJ1gnQ4nAN69o8ONy3LjRYKyJB4pv3iVvXo7NMfA9KkcsnT7TP1xSw2ECWllbDA3Uqy6qE4vCbtDyFJLVI3NSJHct1dvFLnnqUXKd7k8DaQq7Apk2xMd3KZQZ1TLAoiG5rJYvZ0JqunSfd3BL9CJk7emGsAqhue4Vl5XBtTNwCC4ayHoCGhA6fCVmfED/f0/YcgEyMV0A3VafUEzULHFdG/nJkfqJ8+cE+g4/pxfl+vY2yfSFkX7yXeGBA8NWfy8uSns+SHBzYNhZbEYPYgvefZjOitGX9zITG7ut9MAfLWBjF/SExE+8IXyC5/FbrwFhwwocM73/n/TLXuAYs/4WyZm5NtaX2Z44GqUjc4dQDG8mU5/j6T6qZj8fWj2ArvZXr1yIiZ9JxMaYeyqYCTBsYfnM1pXUwwYUsiQzZhbBhiH4hPwcIX1zx/8toj7rL4X9Y94J8rsVQUGSx1vXpMtvTnyEublih9I4/zTFaEDDEgvrXj4DOcAP917AzU5iCldEjPeqJViTVWrrplS4nc3078jET5dYLgATGfsXNIFCzp9dQEOi+fw51sSy9YNQHrqfzeAUs3bMt770pxBVI9plGi/5vg9G5YzrfhKGBQ== X-Forefront-Antispam-Report: CIP:216.228.117.161; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:dc6edge2.nvidia.com; CAT:NONE; SFS:(13230022)(4636009)(396003)(39860400002)(376002)(136003)(346002)(451199015)(36840700001)(46966006)(40470700004)(4326008)(83380400001)(2616005)(16526019)(186003)(1076003)(26005)(6286002)(47076005)(336012)(426003)(356005)(7636003)(82740400003)(36860700001)(2906002)(5660300002)(8936002)(40460700003)(40480700001)(55016003)(82310400005)(478600001)(7696005)(107886003)(6666004)(8676002)(70206006)(70586007)(41300700001)(316002)(54906003)(110136005)(86362001)(66899015)(36756003); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2022 10:45:06.9163 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 227ca4d6-3f98-40fd-356c-08dabe51a382 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.117.161]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT060.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4508 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 The transfer domain rule is able to match traffic wire/vport origin which are corresponding to two kinds of underlayer resources. Wire means traffic arrives from the uplink port while vport means traffic initiated from VF/SF. In customer deployments, they usually match only one kind of traffic in single flow table: either from wire or from vport. PMD can save significant resources if passing special hint from rte layer. There are two possible approaches, using IPv4 as an example: 1. Use pattern item. pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end "ANY_VPORT" needs to be present in each async rule even if it's just a hint. No value to match. 2. Add special flags into table_attr. It will be: template_table 0 create table_id 0 group 1 transfer vf_orig Approach 1 needs to specify the pattern in each flow rules which wastes memory and not end user friendly. This patch takes the 2nd approach and introduce one new member specialize into rte_flow_table_attr to indicate async flow table matching optimization: from wire, from vport. It helps to save underlayer memory and also on insertion rate. By default, there is no hint, so the behavior of the transfer domain doesn't change. 1. Match wire origin only flow template_table 0 create group 0 priority 0 transfer wire_orig... 2. Match vf origin only flow template_table 0 create group 0 priority 0 transfer vport_orig... Signed-off-by: Rongwei Liu Acked-by: Ori Kam v2: Move the new field to template table attribute. v4: Mark it as optional and clear the concept. --- app/test-pmd/cmdline_flow.c | 26 +++++++++++++++++ doc/guides/prog_guide/rte_flow.rst | 15 ++++++++++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 +- lib/ethdev/rte_flow.h | 32 +++++++++++++++++++++ 4 files changed, 75 insertions(+), 1 deletion(-) diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index 88108498e0..15f2af9b40 100644 --- a/app/test-pmd/cmdline_flow.c +++ b/app/test-pmd/cmdline_flow.c @@ -184,6 +184,8 @@ enum index { TABLE_INGRESS, TABLE_EGRESS, TABLE_TRANSFER, + TABLE_TRANSFER_WIRE_ORIG, + TABLE_TRANSFER_VPORT_ORIG, TABLE_RULES_NUMBER, TABLE_PATTERN_TEMPLATE, TABLE_ACTIONS_TEMPLATE, @@ -1158,6 +1160,8 @@ static const enum index next_table_attr[] = { TABLE_INGRESS, TABLE_EGRESS, TABLE_TRANSFER, + TABLE_TRANSFER_WIRE_ORIG, + TABLE_TRANSFER_VPORT_ORIG, TABLE_RULES_NUMBER, TABLE_PATTERN_TEMPLATE, TABLE_ACTIONS_TEMPLATE, @@ -2933,6 +2937,18 @@ static const struct token token_list[] = { .next = NEXT(next_table_attr), .call = parse_table, }, + [TABLE_TRANSFER_WIRE_ORIG] = { + .name = "wire_orig", + .help = "affect rule direction to transfer", + .next = NEXT(next_table_attr), + .call = parse_table, + }, + [TABLE_TRANSFER_VPORT_ORIG] = { + .name = "vport_orig", + .help = "affect rule direction to transfer", + .next = NEXT(next_table_attr), + .call = parse_table, + }, [TABLE_RULES_NUMBER] = { .name = "rules_number", .help = "number of rules in table", @@ -8993,6 +9009,16 @@ parse_table(struct context *ctx, const struct token *token, case TABLE_TRANSFER: out->args.table.attr.flow_attr.transfer = 1; return len; + case TABLE_TRANSFER_WIRE_ORIG: + if (!out->args.table.attr.flow_attr.transfer) + return -1; + out->args.table.attr.specialize = RTE_FLOW_TRANSFER_WIRE_ORIG; + return len; + case TABLE_TRANSFER_VPORT_ORIG: + if (!out->args.table.attr.flow_attr.transfer) + return -1; + out->args.table.attr.specialize = RTE_FLOW_TRANSFER_VPORT_ORIG; + return len; default: return -1; } diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index 3e6242803d..d9ca041ae4 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -3605,6 +3605,21 @@ and pattern and actions templates are created. &actions_templates, nb_actions_templ, &error); +Table Attribute: Specialize +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Application can help optimizing underlayer resources and insertion rate +by specializing template table. +Specialization is done by providing hints +in the template table attribute ``specialize``. + +This attribute is not mandatory for each PMD to implement. +If a hint is not supported, it will be silently ignored, +and no special optimization is done. + +If a table is specialized, the application should make sure the rules +comply with the table attribute. + Asynchronous operations ----------------------- diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index 96c5ae0fe4..b3238415f4 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -3145,7 +3145,8 @@ It is bound to ``rte_flow_template_table_create()``:: flow template_table {port_id} create [table_id {id}] [group {group_id}] - [priority {level}] [ingress] [egress] [transfer] + [priority {level}] [ingress] [egress] + [transfer [vport_orig] [wire_orig]] rules_number {number} pattern_template {pattern_template_id} actions_template {actions_template_id} diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index 8858b56428..1eab12796f 100644 --- a/lib/ethdev/rte_flow.h +++ b/lib/ethdev/rte_flow.h @@ -5186,6 +5186,34 @@ rte_flow_actions_template_destroy(uint16_t port_id, */ struct rte_flow_template_table; +/** + * @warning + * @b EXPERIMENTAL: this API may change without prior notice. + * + * Special optional flags for template table attribute. + * Each bit stands for a table specialization + * offering a potential optimization at PMD layer. + * PMD can ignore the unsupported bits silently. + */ +enum rte_flow_template_table_specialize { + /** + * Specialize table for transfer flows which come only from wire. + * It allows PMD not to allocate resources for non-wire originated traffic. + * This bit is not a matching criteria, just an optimization hint. + * Flow rules which match non-wire originated traffic will be missed + * if the hint is supported. + */ + RTE_FLOW_TRANSFER_WIRE_ORIG = RTE_BIT32(0), + /** + * Specialize table for transfer flows which come only from vport (e.g. VF, SF). + * It allows PMD not to allocate resources for non-vport originated traffic. + * This bit is not a matching criteria, just an optimization hint. + * Flow rules which match non-vport originated traffic will be missed + * if the hint is supported. + */ + RTE_FLOW_TRANSFER_VPORT_ORIG = RTE_BIT32(1), +}; + /** * @warning * @b EXPERIMENTAL: this API may change without prior notice. @@ -5201,6 +5229,10 @@ struct rte_flow_template_table_attr { * Maximum number of flow rules that this table holds. */ uint32_t nb_flows; + /** + * Optional hint flags for PMD optimization. + */ + enum rte_flow_template_table_specialize specialize; }; /** -- 2.27.0