From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) by dpdk.org (Postfix) with ESMTP id 6F7D823D for ; Mon, 30 Jul 2018 18:20:01 +0200 (CEST) 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=jcuJcdnlVe0mqkSFXPN9GkWcvn/52AMd+ESRMqVheBc=; b=qFO5t0/xxTuwTUsYrpW/6ClUeo1Q5ZUjHEJwsLy8eymggvk5Wwxs4tqk04zEsNdB70eTpXwIi9o2jQaqsPsEh2DEMI+/oeihvPE8ouQR0AwPvSwKmCgrbkF6L00xib8Zk5MwU9UwDuA0cR9zbE3w1xlRuMZibKaPcOoeZXiWhKg= Received: from localhost.localdomain (141.226.120.58) by DB6PR05MB3429.eurprd05.prod.outlook.com (2603:10a6:6:1e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.17; Mon, 30 Jul 2018 16:19:58 +0000 From: Ori Kam To: xuemingl@mellanox.com, dekelp@mellanox.com, shahafs@mellanox.com, adrien.mazarguil@6wind.com, thomas@monjalon.net, yskoh@mellanox.com, ferruh.yigit@intel.com, arybchenko@solarflare.com Cc: dev@dpdk.org, orika@mellanox.com Date: Mon, 30 Jul 2018 19:19:25 +0300 Message-Id: <1532967565-13962-1-git-send-email-orika@mellanox.com> X-Mailer: git-send-email 1.7.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [141.226.120.58] X-ClientProxiedBy: VI1PR0202CA0036.eurprd02.prod.outlook.com (2603:10a6:803:14::49) To DB6PR05MB3429.eurprd05.prod.outlook.com (2603:10a6:6:1e::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21cf8355-2db2-4f2f-bd3a-08d5f6384c30 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB6PR05MB3429; X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3429; 3:mHSSWCMIynASzUMg48WAUUPv3DCGFcATZhsbnHUCEKe67ZhOjBQtpsFHY3+0VcaSqjL96rMFtLp8A2WQqYWY6vO4QO2ObghkPgEdiyOfNKcBVeFY6N4NUUqXMJ1mZJe0XxqaVCoDScQ42wBZItcTTzzUdXKg1Qr6XdQPt5K6hTVRQGQAXrX36pjmTk7XTVqnxWhGtXGG4Q4f5HFmjZM26gmG1qViwcZCwcUs/Nqqv4wMLP07Y5q2XHTLkmqTU7lp; 25:6Z/wZjVMWPIbQR5VgFZawVZ6ti3hGfenzA9rfYrlEyVWZV9MlHnMunANjaZrEAB9+hJhOcMTjc7y0JE3MG1+7pzwWtFv1wLe1IbRWd/Ve2DxAVzs4ot+LRR3clDL29CrfrzO4H1NHlCrWO8mu4bvqg3f0gqLkKVFK3Gvz1dfa6fDQjIiVj/RNYKAuDcGKT+u17QwTNRScN8vzGborpjGUdDk1G4XgPNyWBICPuXo7ZyjbzYEqIiKgzQRAoIyt/G3pY0M1AiZYdtgrv+ZXt4kcFW+Q7efNo0KrOQjr56WCG+ncIm7+jKr/cIj9b/ORPBjR2J2BTIXgd7igp7PQsZ+yA==; 31:JIoTSpFZyLVmtfKFmUJ8kCm1qJtZlmh0XSOUHKKjK4NIor+TdnF6WJcfZ3fFtUPUyE9y7XGB1AtxjjKN8lwFnUTgcrX1nMRy1X1IHxL+IRJkVFufc5u/CoL3qsMOONsNBCx8QrSiFxVlwZKQplYJOBk53MP0Yq9amDocXNKQeJT2LywDSqp6VB/P5RKUrIwh+QaIJvhf4T3rhVzL2EiPlFCst85IK1BQDmm8RVqTJbw= X-MS-TrafficTypeDiagnostic: DB6PR05MB3429: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=orika@mellanox.com; X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3429; 20:ts2XvJrfRI971xfaUFBAvTlIO2VVbbejGG7qWNPNMficEB957jQgtKGe4Dey9YV5skiTCdGpA3nVuLQnip9tAcoFlMxhvtvb7dJhV7FGDfKJEm2kG2dpCxRpwIU65w1QBR6tLorX4cGYyCSe/zafuVd242lcxAnMp2zj1ifMEx88OMYFrdQnXo5TVstRsgmDetHws9UpeJ4xiiQDVh9O84lJwLeEY2FwMOGo1PjGzd993Y5BheLAiUhp+eXatclIFu2vg8wxFrNKL/Qu6SjGmoMJZ+LcFnc+cGn8WlG3Hqk03fkO7YLrCx3gxegK9m9wJBQ9nrMA5aqWLmH7gmzx4tm75/XFb8oSngPZdthjSTDhnIlKxL9SiPyCuIA4JDMHKE8XyprQz+5y/yg456uN0PWRPxbUfUptx80hR5yijhXeqtd734HBxvvsH9ZnZqCRD2buuFhjz3EqCoRmNVcbstkhUupMy/DKpu5ptWxmioy42zszr/phw9qDax0Tdh5M; 4:GhUsJlGAoZVzM+ZSprJepAlIzy5H/F/GcWInJJMDIhw9lFSXLDcgz6QVs2KozC9lRg2FVlPUfb/yBmPjdO/3PKL5j8dnb9c8XDdIXHBuiKUpsu1e0RefyQMyghp6g9mhcV6dP7+dYci+rZMs0Qk+gzMe2ZoebrvulIOReb25v8fBA935hPtytSIaU1GDceIGVwJrvWjcbd4wmVrE3R8hCAui0+QAWyndmT7GQTJy17EMoR9l7fdB/6b/S95DzIFBlOrfYASqG8x+t3oLP9r/ig== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:DB6PR05MB3429; BCL:0; PCL:0; RULEID:; SRVR:DB6PR05MB3429; X-Forefront-PRVS: 0749DC2CE6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(39860400002)(396003)(376002)(136003)(346002)(366004)(189003)(199004)(31014005)(16526019)(52116002)(51416003)(97736004)(6486002)(305945005)(7736002)(5660300001)(478600001)(8676002)(47776003)(81156014)(81166006)(8936002)(66066001)(68736007)(6506007)(2906002)(386003)(6116002)(26005)(50226002)(50466002)(2616005)(956004)(14444005)(3846002)(107886003)(4326008)(486006)(36756003)(53936002)(48376002)(476003)(86362001)(6666003)(6512007)(25786009)(16586007)(316002)(105586002)(106356001)(41533002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR05MB3429; H:localhost.localdomain; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR05MB3429; 23:BwEdfSsKul9LQXaH44xVc9mvY9vpL+LW2UgN0Gtx6?= =?us-ascii?Q?2E+RnpcrFgy443Qbtk/il6GVsPNF2bZ0q4fwoY58v++BCUUnTY5rSvBChO76?= =?us-ascii?Q?y0CgnWgfgbJvgdZXdnjr1kcgpNWKF/Y8U0hrI8wqhlc6CUPvD9btURvzQFQY?= =?us-ascii?Q?Z9OnfBtFU5CV0pVhlUcMjmf9VoDpGKVhD38RHf5S34j+Ajfd8fDE9BjNnLRq?= =?us-ascii?Q?1kMiVcVu4wH8vVX8iX/zFbDXSIjJ9bAs/D1MIJKPVVj3448vF2gXhfu72m5W?= =?us-ascii?Q?L6RDnJlxCCKrf38kA9raaG9XdjsJMoMvSsfxV1MYaiA3vPvqwMNmPd9xdsND?= =?us-ascii?Q?xgNceiSzlZTSSeiJzdBxA9IHSEp2qJutPk3zTi/4Y5SvFnG1FFQznPt9N6rJ?= =?us-ascii?Q?oiTbP0f+ZgU4m43FEXnebKuY+5sezjq9sKHu6dzO2YClrR9q9X2aAPIqrgCN?= =?us-ascii?Q?UqfC6hGhdySgtn214lhPRttNIy3RUl6XYf34z4/3YXc1bNTv5NMplt6sHYbZ?= =?us-ascii?Q?NpEkn1KSVZ4FBNiGjlVl9LxLXtxFGrYWu46UqZpspN+tjVd48o/KrBKrtNZy?= =?us-ascii?Q?pyIluB2uAE5h5iHhnLdWYEcNtnE/MUKtz40XmhI/fy+c2tC8uxv/cKWGhfvT?= =?us-ascii?Q?AjRFLAsEH7N606v0q+RVNVIJ5GgqT3Zb9PHH8jZ7drvP+eLJSdApoG42iJIP?= =?us-ascii?Q?bkp6lzSSzp57/X+iH6kXfQm/5kmZNY2E08/HU8tOGw30/eQzw/XNVoPsQPWS?= =?us-ascii?Q?ghgWzYSW1MvYRSlWjvIzMlmLHr4Nf/Z/sq8hIIQPs4/93BWMFEgRz/vPFEbA?= =?us-ascii?Q?T6KGV4v0Lhm9ulOF7hmzqmW7ypsOlfaj//IPIV7lYmJhi2NzRTcHKyLS/HOM?= =?us-ascii?Q?oH3sEgIYDUQLNYzpmLy3wxVqSm77cJ7Lc/ZZojVeLp2A+wCXyev6nawu46p3?= =?us-ascii?Q?QjqYhyPK9JDpywkLI09eqyianwsHjpwRUWzE9i11DtEDQL/fpEmollXE/MAt?= =?us-ascii?Q?rU7FUu1/ZTsL9O4OyZAv+iE008drASe8s8URyMDmXCahiJAnqZL5ea9OfXL8?= =?us-ascii?Q?erVkdiLSWRWb41T0GFoM2Xqg4EVAT3XAtlNRvDb/u1kDJE3bOMrm7CiSQzpe?= =?us-ascii?Q?PVKqutUsMQMuA14ym4vXcunCyxYxTMnVk0t7xwh6m9m7epn5btApwzzwsrcp?= =?us-ascii?Q?WG5MWX8Lqu2/hE=3D?= X-Microsoft-Antispam-Message-Info: Abqczp2xHzMG5KGTJmx//K1lhB7czdfVUw19+0vSAqYVqFH8Osw8hGj5dCRpOpdO/xblOflxZZTaGsxNWTHDH4NNFRI4Bvd77X58LREiRgdgFTo3IAIazrgnf9kKrji8QhbpJEft0NeLinql4xcxJivt4JR3Qe6vPZuR1kyYsb49jG7pdy97EgUTG1akecri++PPwIxKKLFxI2ralY/gPpO7ul39AmD4Eh+yKaJ+PobNdSaznS9dTufdCG1wJhUlNuKsNSaCnP5VkpArHHuUokz9J4wrxCj9n38cGVBbh9TPI5p21cOoA5wmmSsZ3yQd8blZNcuIkhdJgkQfUP7vCv0kh15Q7xJD3wxHgTZzsPo= X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3429; 6:VHujEHKZF6/WxIaosGXZuW21Dzd1zGMmKrg/Hjk4SVJLlkLLe72i6AEA6m2wei8lardFCMWOkh7HjazEpDOTCBbpRifViTMXjCcOEBscng/JJ04e+DUYXe2NuECkAUSEtd+jJE3Mn6gsMwGV7MgRO8b9l2CsKyhcDYAugvp6081aoDgbLlKjoLao/GpJq9oGyBEBFf7QeCQrVhaFjsO2MHlXN632T8s7mDHLp5bDfEcPWILmIvhNUdGEO4aTfZhUCzYJTRJ0rNB5dEx9HuLaaQD3+Etx1BEQlN3vEWBlw4xx74u1bH3rZNCvNIGpgF6HrpqcVgFIlHoj6/3uvMa1zZMzprhxCqAqRK72t1zkqfltPZkDcLeWj7ghXrNfYZNnM019JNGaUjAztuihbhlCLA7gzy11bBtuD2zF7UbKakpCwmuKw+rnouYIahc2Snda3/R25QhENH9ZhU0SXeGSVA==; 5:IGvPX4a6FBdkfdfDHcSbdrt4pvdFai7URWWznFSDbXeZHS1p+zq/MVsfFBu9rQwz3mi2VT+gMV7MzoXWqpqBopOlcJmBPMW+6tiBEwsleTMl941sAWSm7klOXfc7F479Q7mpQF4dibd6YmIY1DHi0i650v4NvTHJfNem6Vdz8Bo=; 7:01klNDWWO9aVN+xBBAPIvLVehxLaFLIS46jLSEB0U39Qtmrlm0XkuNVwe9iQFqA8RliNwTh6R8fOr+POMWOpuPe8u7yCsS6LkDTLp/vlPjuk9eGdmdD/6kWfxBmdb2sDCDc7vyM5cJuDVeQGsc7YwThsqs4G05Ki0NnE4QFQBM2JyK4oYM0311kbNC690r5tgEm33VXQ379a2iJdYu96O0q8hxUcqSQ2EnY53DTO1/hQhTRWTrwIrDEWxGy9X/It SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2018 16:19:58.1544 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21cf8355-2db2-4f2f-bd3a-08d5f6384c30 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR05MB3429 Subject: [dpdk-dev] [RFC] ethdev: add generic L2/L3 tunnel encapsulation actions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 16:20:01 -0000 Currenlty the encap/decap actions only support encapsulation of VXLAN and NVGRE L2 packets. There is a need to add more L2 tunnels and also L3 tunnels. One issue with the current approch is the duplication of code. For example the code for handling NVGRE and VXLAN are exactly the same, and each new tunnel will have the same exact structure. Last issue with the current approach is the use of rte_items. The most significant issue with that is that the PMD needs to convert the items and this hurts the insertion rate. Other issue is that the rte_item has 3 members while we only need the spec (last and mask are useless). I know that the extra member have only small memory impact but considering that we can have millions of rules, this became more important consideration, and it is bad practice to add a variable that is never used. My suggestion is to create 2 commands, one for encapsulation of L2 packets and one for encapsulation of L3 tunnels. The parameters for those functions will be a uint8_t buffer with a length parameter. The current approach is not implemented yet in drivers yet, and is marked as experimental, so it should be removed. Any comments will be hugely appreciated. Signed-off-by: Ori Kam --- lib/librte_ethdev/rte_flow.h | 111 ++++++++++++++++++------------------------ 1 files changed, 47 insertions(+), 64 deletions(-) diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index f8ba71c..3549d7d 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -1473,38 +1473,37 @@ enum rte_flow_action_type { RTE_FLOW_ACTION_TYPE_OF_PUSH_MPLS, /** - * Encapsulate flow in VXLAN tunnel as defined in - * rte_flow_action_vxlan_encap action structure. + * Encapsulate flow with header tunnel as defined in + * rte_flow_action_tunnel_encap action structure. * - * See struct rte_flow_action_vxlan_encap. + * See struct rte_flow_action_tunnel_encap. */ - RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, /** - * Decapsulate outer most VXLAN tunnel from matched flow. + * Decapsulate outer most tunnel from matched flow. * - * If flow pattern does not define a valid VXLAN tunnel (as specified by - * RFC7348) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION - * error. + * The flow pattern must have a valid tunnel header. */ - RTE_FLOW_ACTION_TYPE_VXLAN_DECAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, /** - * Encapsulate flow in NVGRE tunnel defined in the - * rte_flow_action_nvgre_encap action structure. + * Remove L2 header and encapsulate with header tunnel as defined in + * rte_flow_action_tunnel_encap_l3 action structure. * - * See struct rte_flow_action_nvgre_encap. + * See struct rte_flow_action_tunnel_encap_l3. */ - RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP_L3, /** - * Decapsulate outer most NVGRE tunnel from matched flow. + * Decapsulate outer most tunnel from matched flow, + * and encap the remaining header with the given one. * - * If flow pattern does not define a valid NVGRE tunnel (as specified by - * RFC7637) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION - * error. + * The flow pattern must have a valid tunnel header. + * + * See struct rte_flow_action_tunnel_decap_l3. */ - RTE_FLOW_ACTION_TYPE_NVGRE_DECAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP_L3, }; /** @@ -1803,69 +1802,53 @@ struct rte_flow_action_of_push_mpls { * @warning * @b EXPERIMENTAL: this structure may change without prior notice * - * RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP - * - * VXLAN tunnel end-point encapsulation data definition - * - * The tunnel definition is provided through the flow item pattern, the - * provided pattern must conform to RFC7348 for the tunnel specified. The flow - * definition must be provided in order from the RTE_FLOW_ITEM_TYPE_ETH - * definition up the end item which is specified by RTE_FLOW_ITEM_TYPE_END. - * - * The mask field allows user to specify which fields in the flow item - * definitions can be ignored and which have valid data and can be used - * verbatim. + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP * - * Note: the last field is not used in the definition of a tunnel and can be - * ignored. - * - * Valid flow definition for RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP include: - * - * - ETH / IPV4 / UDP / VXLAN / END - * - ETH / IPV6 / UDP / VXLAN / END - * - ETH / VLAN / IPV4 / UDP / VXLAN / END + * Tunnel end-point encapsulation data definition * + * The tunnel definition is provided through raw buffer that holds + * the headers that should encapsulate the packet. + * The given encapsulation should be a valid packet header. */ -struct rte_flow_action_vxlan_encap { - /** - * Encapsulating vxlan tunnel definition - * (terminated by the END pattern item). - */ - struct rte_flow_item *definition; +struct rte_flow_action_tunnel_encap { + uint8_t *buf; + uint16_t size; }; /** * @warning * @b EXPERIMENTAL: this structure may change without prior notice * - * RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP_L3 * - * NVGRE tunnel end-point encapsulation data definition + * Tunnel end-point encapsulation after removing the L2 header, + * including the vlan header if any. * - * The tunnel definition is provided through the flow item pattern the - * provided pattern must conform with RFC7637. The flow definition must be - * provided in order from the RTE_FLOW_ITEM_TYPE_ETH definition up the end item - * which is specified by RTE_FLOW_ITEM_TYPE_END. + * The tunnel definition is provided through raw buffer that holds + * the headers that should encapsulate the packet. * - * The mask field allows user to specify which fields in the flow item - * definitions can be ignored and which have valid data and can be used - * verbatim. + * The given encapsulation should be a valid packet header. + */ +struct rte_flow_action_tunnel_encap_l3 { + uint8_t *buf; + uint16_t size; +}; + +/** + * @warning + * @b EXPERIMENTAL: this structure may change without prior notice * - * Note: the last field is not used in the definition of a tunnel and can be - * ignored. + * RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP_L3 * - * Valid flow definition for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include: + * Decap the outer header and add the L2 header based on the given buffer. * - * - ETH / IPV4 / NVGRE / END - * - ETH / VLAN / IPV6 / NVGRE / END + * The flow pattern must have a valid tunnel packet. * + * The given encapsulation should be a valid L2 packet header. */ -struct rte_flow_action_nvgre_encap { - /** - * Encapsulating vxlan tunnel definition - * (terminated by the END pattern item). - */ - struct rte_flow_item *definition; +struct rte_flow_action_tunnel_decap_l3 { + uint8_t *buf; + uint16_t size; }; /* -- 1.7.1