Message ID | 20200625160348.26220-1-getelson@mellanox.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 dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 55C20A0350; Thu, 25 Jun 2020 18:04:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9F1775F69; Thu, 25 Jun 2020 18:04:05 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10041.outbound.protection.outlook.com [40.107.1.41]) by dpdk.org (Postfix) with ESMTP id A8F62F04 for <dev@dpdk.org>; Thu, 25 Jun 2020 18:04:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H1ORR9oWJrtFGcmd2ERAcvRDSGIKVmVi0XS6DV+zn/ZWn9mL3j0UB0OeYlGgMQSyqx5BDwxbRajXbza4xkNDIAP03VLmhnNQbdkbv6YaaiN2dY3ZZtEaVYzZWgIHI+ZbzIP84REL2ECLrMlvi/fYf6Batjs/lDwKVPCuM9S0Oqrun9Nw/kGqkhro7s4anbtBj94qGJvsw/q+tFFmV+3+rK90JpuKD5ag4tZ55i2biDNAh59PrTtJE+82ONVFP37qEU8QD2RoTHXmSw82gPT6TP/ADMD16VQDOn6NcbSctGM530co2YNLfUFXOc3dTL6YJv+SoDeeDoFHKktrEvm8cw== 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=IBceDkKG2gnMkFJVkisZjfibq7RVVUCrDtWd4WL+YxI=; b=nVn+Nmkqam3+8W4Czawatb/IJymRop7qp7d0hLVLVzyHV4FlnnneWmPwzg6gNN6dNnF9SawgoAdnjnTHcmNKRiCubKLYxrKrpTcOXIiBdaiDLkQFP/EMgQOI/7jVl1nK8jwfaIZ2zY4F4dZa70ojRkGOOzgro2OLaO+yI1g6AkvqZTbBgEErQlDqr9OrOCWroj2qRNnvbCDkKAyF1MDNrKmSm3WV/rSo2/jsrBusd6i3LtmqmviO5rOh3Vs1eepLqKFmk/LqiOn+CHEgUhoJkUowarYHR9OFfAehP9O6pfCTJf60oviEy0cuYPl1XXWLkFXfKpQvxT8OM6G7yijAAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IBceDkKG2gnMkFJVkisZjfibq7RVVUCrDtWd4WL+YxI=; b=T0TA3I+m2JioYwbDAVQhfWRK5JaLNIWuxMdhvJ/001FJOGzM278tlLEeuqhrE9UoJG3VrqfUl+niYa4H804r4ZD+ezFR6mPC6IFpc4yBf24ZQNDDBbBJtujrhX+luSiQh5HTXTFU8Ix/cPOiyGOjtBQ+ppg+YoeUHDVpEmjDeCk= Authentication-Results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=mellanox.com; Received: from DB8PR05MB6761.eurprd05.prod.outlook.com (2603:10a6:10:139::21) by DB6PR0501MB2552.eurprd05.prod.outlook.com (2603:10a6:4:5f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Thu, 25 Jun 2020 16:04:00 +0000 Received: from DB8PR05MB6761.eurprd05.prod.outlook.com ([fe80::10cf:d50d:bee:a43]) by DB8PR05MB6761.eurprd05.prod.outlook.com ([fe80::10cf:d50d:bee:a43%5]) with mapi id 15.20.3131.023; Thu, 25 Jun 2020 16:04:00 +0000 From: Gregory Etelson <getelson@mellanox.com> To: dev@dpdk.org Cc: getelson@mellanox.com, matan@mellanox.com, rasland@mellanox.com Date: Thu, 25 Jun 2020 19:03:46 +0300 Message-Id: <20200625160348.26220-1-getelson@mellanox.com> X-Mailer: git-send-email 2.25.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR01CA0124.eurprd01.prod.exchangelabs.com (2603:10a6:208:168::29) To DB8PR05MB6761.eurprd05.prod.outlook.com (2603:10a6:10:139::21) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mellanox.com (176.230.225.181) by AM0PR01CA0124.eurprd01.prod.exchangelabs.com (2603:10a6:208:168::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Thu, 25 Jun 2020 16:03:59 +0000 X-Mailer: git-send-email 2.25.1 X-Originating-IP: [176.230.225.181] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6ce639c7-67a8-4139-d157-08d819215f63 X-MS-TrafficTypeDiagnostic: DB6PR0501MB2552: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtFwd X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: <DB6PR0501MB2552501B8762BA91A82A9145A8920@DB6PR0501MB2552.eurprd05.prod.outlook.com> X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-Forefront-PRVS: 0445A82F82 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yeJn1RnU8TLoJ5DMSdWsll2er6IlfVxQ3cKKvB8o356Ee/kPCV1Eqmnj6kGJalfIIZ+Yt7wSDkHLcDLteGdAGUN6A8c0dDXOssndyHiBnsqX3TQBdcNt2u8LgP+AUyQTr9CKBDP269HGIk6CB26U2I5rLp9OwubcKAJwPJWh9xzgvSzkk0w63cbDYwuA4YsopOaucEyoT1zDnKF1x5qESaXjVVU5ViJfBkNUwP05ihjUq+rYAw63263iSirDs55ogBZg/0aS0Lb7X+MbokkbsPkVGIdbsiKCxOY9bIaIAq9FYKfggBGmx+emuT5nDWhv1g3CJwxBZwqXdUt4KEmEuO5ULOOXPwGYmPtVzpfUnDauqMqSYFgR/OSj/x9wnyn3kNEvu9MxUyHjv6325kME8Q== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR05MB6761.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(366004)(396003)(376002)(8886007)(83380400001)(36756003)(316002)(2906002)(26005)(186003)(66946007)(66476007)(66556008)(16526019)(55016002)(86362001)(5660300002)(8676002)(478600001)(8936002)(7696005)(52116002)(966005)(6666004)(1076003)(107886003)(4326008)(6916009)(2616005)(956004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: UlZOQSQks/v7Ej4KbOZQZCl6UgzQZHkKGDZOPP+Yvc5lCtOHUnJ4OdinG3sp3tOxNUO52me1sqAYRx+ae0L66L84KLOG6nMjXDWKUQHwIC5RQ5D1mRqG/0cxsG13MOuPR9MBvHgXHIiUEMVF6p9GRgom/4pFqXF1TvEevf0Qh30a2pb96pnbZAN2qK2yjowGhOX8L4nwmpaDWeYaygTeTQFP0Kd1/wdIpW5mjdeVxeHYWYvFJO0XSUbePJU48+wm8uDpbydQ7lfjGTdsSkCtmGfBZP0t79bNvc8Y9TowYOz/5UxNYn7oQ77fHD0Vb56CPy7K1v8rgr4busMqGtqayE7MXNoFHnPM9Uws+JIugPH68FSg4++oewQgQ+UhdcSI9IzfXJPzyMRcTzw6Q9QzQnQ24Rtp3aXyj92565xkaFigi49zfreQlYB6QIzbh5ottuVH1HVToOr9mIUvlLOG54PfN9AyOy7nV2lehhRNKNc= X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce639c7-67a8-4139-d157-08d819215f63 X-MS-Exchange-CrossTenant-AuthSource: DB8PR05MB6761.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2020 16:03:59.9709 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Xk6CNZGeRKGjOMUTl17ng6yuAvDrMR3wvnTc+KXuOw+Tkh2QMTJnuI5MfMUn0Rufkx9QWfPReNDz5Lqas8Nvpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0501MB2552 Subject: [dpdk-dev] [PATCH 0/2] ethdev: tunnel offload model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 |
ethdev: tunnel offload model
|
|
Message
Gregory Etelson
June 25, 2020, 4:03 p.m. UTC
Hardware vendors implement tunneled traffic offload techniques differently. Although RTE flow API provides tools capable to offload all sorts of network stacks, software application must reference this hardware differences in flow rules compilation. As the result tunneled traffic flow rules that utilize hardware capabilities can be different for the same traffic. Tunnel port offload proposed in [1] provides software application with unified rules model for tunneled traffic regardless underlying hardware. - The model introduces a concept of a virtual tunnel port (VTP). - The model uses VTP to offload ingress tunneled network traffic with RTE flow rules. - The model is implemented as set of helper functions. Each PMD implements VTP offload according to underlying hardware offload capabilities. Applications must query PMD for VTP flow items / actions before using in creation of a VTP flow rule. The model components: - Virtual Tunnel Port (VTP) is a stateless software object that describes tunneled network traffic. VTP object usually contains descriptions of outer headers, tunnel headers and inner headers. - Tunnel Steering flow Rule (TSR) detects tunneled packets and delegates them to tunnel processing infrastructure, implemented in PMD for optimal hardware utilization, for further processing. - Tunnel Matching flow Rule (TMR) verifies packet configuration and runs offload actions in case of a match. Application actions: 1 Initialize VTP object according to tunnel network parameters. 2 Create TSR flow rule: 2.1 Query PMD for VTP actions: application can query for VTP actions more than once int rte_flow_tunnel_decap_set(uint16_t port_id, struct rte_flow_tunnel *tunnel, struct rte_flow_action **pmd_actions, uint32_t *num_of_pmd_actions, struct rte_flow_error *error); 2.2 Integrate PMD actions into TSR actions list. 2.3 Create TSR flow rule: flow create <port> group 0 match {tunnel items} / end actions {PMD actions} / {App actions} / end 3 Create TMR flow rule: 3.1 Query PMD for VTP items: application can query for VTP items more than once int rte_flow_tunnel_match(uint16_t port_id, struct rte_flow_tunnel *tunnel, struct rte_flow_item **pmd_items, uint32_t *num_of_pmd_items, struct rte_flow_error *error); 3.2 Integrate PMD items into TMR items list: 3.3 Create TMR flow rule flow create <port> group 0 match {PMD items} / {APP items} / end actions {offload actions} / end The model provides helper function call to restore packets that miss tunnel TMR rules to its original state: int rte_flow_get_restore_info(uint16_t port_id, struct rte_mbuf *mbuf, struct rte_flow_restore_info *info, struct rte_flow_error *error); rte_tunnel object filled by the call inside rte_flow_restore_info *info parameter can be used by the application to create new TMR rule for that tunnel. The model requirements: Software application must initialize rte_tunnel object with tunnel parameters before calling rte_flow_tunnel_decap_set() & rte_flow_tunnel_match(). PMD actions array obtained in rte_flow_tunnel_decap_set() must be released by application with rte_flow_action_release() call. Application can release the actionsfter TSR rule was created. PMD items array obtained with rte_flow_tunnel_match() must be released by application with rte_flow_item_release() call. Application can release the items after rule was created. However, if the application needs to create additional TMR rule for the same tunnel it will need to obtain PMD items again. Application cannot destroy rte_tunnel object before it releases all PMD actions & PMD items referencing that tunnel. [1] https://mails.dpdk.org/archives/dev/2020-June/169656.html Eli Britstein (1): ethdev: tunnel offload model Gregory Etelson (1): ethdev: allow negative values in flow rule types doc/guides/prog_guide/rte_flow.rst | 105 ++++++++++++ lib/librte_ethdev/rte_ethdev_version.map | 5 + lib/librte_ethdev/rte_flow.c | 142 +++++++++++++++- lib/librte_ethdev/rte_flow.h | 196 +++++++++++++++++++++++ lib/librte_ethdev/rte_flow_driver.h | 32 ++++ 5 files changed, 474 insertions(+), 6 deletions(-)
Comments
On 6/25/20 7:03 PM, Gregory Etelson wrote: > Hardware vendors implement tunneled traffic offload techniques > differently. Although RTE flow API provides tools capable to offload > all sorts of network stacks, software application must reference this > hardware differences in flow rules compilation. As the result tunneled > traffic flow rules that utilize hardware capabilities can be different > for the same traffic. > > Tunnel port offload proposed in [1] provides software application with > unified rules model for tunneled traffic regardless underlying > hardware. > - The model introduces a concept of a virtual tunnel port (VTP). > - The model uses VTP to offload ingress tunneled network traffic > with RTE flow rules. > - The model is implemented as set of helper functions. Each PMD > implements VTP offload according to underlying hardware offload > capabilities. Applications must query PMD for VTP flow > items / actions before using in creation of a VTP flow rule. > > The model components: > - Virtual Tunnel Port (VTP) is a stateless software object that > describes tunneled network traffic. VTP object usually contains > descriptions of outer headers, tunnel headers and inner headers. > - Tunnel Steering flow Rule (TSR) detects tunneled packets and > delegates them to tunnel processing infrastructure, implemented > in PMD for optimal hardware utilization, for further processing. > - Tunnel Matching flow Rule (TMR) verifies packet configuration and > runs offload actions in case of a match. > > Application actions: > 1 Initialize VTP object according to tunnel > network parameters. > 2 Create TSR flow rule: > 2.1 Query PMD for VTP actions: application can query for VTP actions > more than once > int > rte_flow_tunnel_decap_set(uint16_t port_id, > struct rte_flow_tunnel *tunnel, > struct rte_flow_action **pmd_actions, > uint32_t *num_of_pmd_actions, > struct rte_flow_error *error); > > 2.2 Integrate PMD actions into TSR actions list. > 2.3 Create TSR flow rule: > flow create <port> group 0 > match {tunnel items} / end > actions {PMD actions} / {App actions} / end > > 3 Create TMR flow rule: > 3.1 Query PMD for VTP items: application can query for VTP items > more than once > int > rte_flow_tunnel_match(uint16_t port_id, > struct rte_flow_tunnel *tunnel, > struct rte_flow_item **pmd_items, > uint32_t *num_of_pmd_items, > struct rte_flow_error *error); > > 3.2 Integrate PMD items into TMR items list: > 3.3 Create TMR flow rule > flow create <port> group 0 > match {PMD items} / {APP items} / end > actions {offload actions} / end > > The model provides helper function call to restore packets that miss > tunnel TMR rules to its original state: > int > rte_flow_get_restore_info(uint16_t port_id, > struct rte_mbuf *mbuf, > struct rte_flow_restore_info *info, > struct rte_flow_error *error); > > rte_tunnel object filled by the call inside > rte_flow_restore_info *info parameter can be used by the application > to create new TMR rule for that tunnel. > > The model requirements: > Software application must initialize > rte_tunnel object with tunnel parameters before calling > rte_flow_tunnel_decap_set() & rte_flow_tunnel_match(). > > PMD actions array obtained in rte_flow_tunnel_decap_set() must be > released by application with rte_flow_action_release() call. > Application can release the actionsfter TSR rule was created. > > PMD items array obtained with rte_flow_tunnel_match() must be released > by application with rte_flow_item_release() call. Application can > release the items after rule was created. However, if the application > needs to create additional TMR rule for the same tunnel it will need > to obtain PMD items again. > > Application cannot destroy rte_tunnel object before it releases all > PMD actions & PMD items referencing that tunnel. > > [1] https://mails.dpdk.org/archives/dev/2020-June/169656.html Three copies of the above text here, in 2/2 description and 2/2 content in DPDK documentation is too much. IMHO, it should only one place in the documentation with brief summary in patch/series description.