From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0065.outbound.protection.outlook.com [104.47.0.65]) by dpdk.org (Postfix) with ESMTP id 8A1A11BAA6 for ; Tue, 5 Jun 2018 17:48:50 +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=qwJr0T61+F245QUZbHlskxM+laIqDElRYXkfin+nQgI=; b=otRewhTsI1tdd68MOFDTWEgTTpLkAfKR4aJ5/q5gi486Ztox66wPwL78sLCaa49LkX3HxvR4T3A2mohIaCtuLARdjdyvh0YxJgaTQ2SN7pQdErTZFPy8ns/IaMOhG1u2yS5keIFXLU+zXktjZxHXNxqERR99nTPAjn6fb4HGcr4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=orika@mellanox.com; Received: from localhost.localdomain (141.226.120.58) by DB6PR05MB3431.eurprd05.prod.outlook.com (2603:10a6:6:1e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Tue, 5 Jun 2018 15:48:45 +0000 From: Ori Kam To: ferruh.yigit@intel.com, declan.doherty@intel.com, dev@dpdk.org, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com, orika@mellanox.com Date: Tue, 5 Jun 2018 18:48:28 +0300 Message-Id: <1528213708-5247-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: AM6PR03CA0032.eurprd03.prod.outlook.com (2603:10a6:20b::45) To DB6PR05MB3431.eurprd05.prod.outlook.com (2603:10a6:6:1e::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB6PR05MB3431; X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3431; 3:jHnHObj8M31NK/liDrJoUkkqnbX7BhSn1vP+jFsBXV++j29ZZmWp2UgeWz0rd209g+USTVahKinZyTNBc+JjtLKuZz8AVD/5XSV/VZ8x4SZN0YIoF0BgVsrsdAZBZmdS4iWSNZzmf6LRB8s5sHoGRZ9Zd9xQRq4j+m3/kJNU8Oz58QgBJNmoR9mKnBWq0dhPbZP3fmzwFWoqKIkYo0G03GodFjxN5Dup0yAjLs5RkkwsrMoqFy0w85WKSPMDgiZf; 25:uz/JrL0DwjY6OiIIX38JQQFB6ZJWMaTB4n6/uIAmhyu2VWXFwwgbX8grqtuYaM7DfuSd+JtF4Tni+d9a5CA7IwojVk3Fg7d4nftBGMdiqvmNt1RMBUsd1ZKoyLQ34qJDchEmMl2dxP+LFTATOrrjzc2Ya0nWPHesWlE0LHfP5tWvTrxwNXhfY5TWuLLHLsJm2hxvFis5AfSVRKhv+iZVFyqNSUWVOEWhjlnDPuWR2S2c8Z6MiKv47lX6O207X35J34j6Jk869PuZtP+E/Pg+F63skokGOhH6VD3K4z06SWJhwMUOWAsCrTq/p6E6+BAuL8JPyRRr6zTDDTxslcwMYQ==; 31:xjdzEwqsrGe736xZC0Py4w9CsR1VBTogs0WdDO8dj9dNwoz+grsfQWQyt9Xm1xCVMedquLWhHT7o+0+/jfkrFNYDtZ/xuEPXvh57DV0hae/fa+4V92yi+KzDS/f2ny4/SSaeQuWtuquoFVvZ/P8zVMhVjqm2w8at1rpHzm+4a7eOj3kbgjbTio4hksjstB49vE4NXHqRgbjHa2ZMy5YkW/aOioMuGCYT6Ntv4TFFLWE= X-MS-TrafficTypeDiagnostic: DB6PR05MB3431: X-LD-Processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3431; 20:stNGfYPBiGzuLseimPBE3iV3aR92k+/tnOjtbb2bC1N6/VvDBYhMErwFyPFof1MXPtt3OQIeSjyjrMtV4BoFVMIMCyvacbJk41yfg2nYHct1Eul0dkZ8ElsBpqz1J/vR731Fe6svPLwdX+N4EU/T/lp9GYF+645L1aN7AgAZfKJmLVTGr6zlMvOJHAlPiLPG/WkbADtWe/VtAybN9sHq77n6Kdh8QI6mLJywTDZcjduJfx6RHr8R2c9gaS3avoiniEjA90Mv1mjSoPMQkwJ91kJ6+oiCHlrw5Rx4aHIId8t9GUDDpAONDHTJ/q6/EcDkCcl6DjXXWdf8ZNUXp0dDTHm9vPPx1b8bICdO4/HKXCWS2+8Vp4kuKUQqs9qw+dVryPaErUEkPWvs1Qsflf5eG20VNwM1UnqrGA4NiyQXutr28yNuVq8iO2MEEcKcP0zhLZktvu+6L585Sq9V2H+zTCMJYmLUuePrGKo7LB6qzcjlwXJd1kGVLwuDRCceo6w6; 4:cLUAYizgKYeewxnEZMzZT5kvBNsmYcNa/quOcpuS+IrdcjYP5QzR0eqI7MA8A0IbFUORHtMOF1SCZozMKgXLahG/4KhtBVpNP9cHinTDjrTp2mCUzHLvuF2NwZB1LtQSlPNbosCiV1dAkUL7SAj0+D+X6J/4CrfFMYfdqRetTildlzN/NJ1FbF8cRJK5ORWb+1mwFr9XvkJvLRj/rLfv1kOJWlRH+eCSJlZa9IOvv20ftPf13n0mQUuGRtRApanqGrv+82C+kJkvJUUwonC8toOwFoxZQ4im7DXbI2/zBv2XXkRcHl0w4VkZ5zGz+mR0r1hlylKF7aTe7x+PP8q1Yw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(788757137089); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DB6PR05MB3431; BCL:0; PCL:0; RULEID:; SRVR:DB6PR05MB3431; X-Forefront-PRVS: 0694C54398 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6069001)(376002)(366004)(39860400002)(39380400002)(346002)(396003)(199004)(189003)(476003)(7736002)(52116002)(25786009)(105586002)(51416003)(47776003)(305945005)(66066001)(106356001)(956004)(2616005)(486006)(316002)(16586007)(6666003)(561944003)(48376002)(50466002)(97736004)(86362001)(2906002)(6512007)(26005)(50226002)(186003)(53936002)(59450400001)(8936002)(68736007)(36756003)(386003)(6486002)(6506007)(3846002)(6116002)(8676002)(478600001)(81156014)(81166006)(5660300001)(16526019); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR05MB3431; H:localhost.localdomain; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB6PR05MB3431; 23:NSOmlWSEFSss8gluetWxcDNqYpqHV/L+VJ5mExjfq?= =?us-ascii?Q?+YVDbxw1lJ8ufPBKYjJ0eiOAs9RdD5JvryaK5X78DIkt6QsbT5aR9dN5cwJw?= =?us-ascii?Q?ZcZl9bLZwAIGISwhD7JFyEx416hpcpRgRHlbW5k3OEVpLTppLXOk0RnIEBk3?= =?us-ascii?Q?0H4HurEpitpDMdmpgOzliarm/BdlW5TbpMPFflXTBRUF63xZSEVWe7z8mJs9?= =?us-ascii?Q?CkfATAop8vgMbw+4oHYdEMBoRyCVRq4JRIKyET6yrEP9fGPX8ugHXxpGykl+?= =?us-ascii?Q?YBd1Ac9xSTgQ1ZoT8T3sq0XE+fZ4wPvuskZjjO2rsB33HSzLMxlS47EuTUGc?= =?us-ascii?Q?Rf6PW6DIYRbgIkms+ZJcfVt5FGKat+ufq6LM9YbQcU7vh1YbQ5OLd8WMe+Yn?= =?us-ascii?Q?ZVFa9d/NC19sEggLj7kG45TnKWAfJasH2Dv118ACGackHoJhYHFSRet3Ozz9?= =?us-ascii?Q?nQBZUFUWewFduHjw8nVp2PQaI3TY9f0v0Q779kD4VjkdPDN7OqocKdxSTpcl?= =?us-ascii?Q?VAhzDdoAeTiqp6VsYvSNflY8LbkfeRNP4cFNHKqSQYPlZ+sGrkrcPGtRp0q7?= =?us-ascii?Q?7LG59McNSrethBhEABSDAMu/cYqpXBXSK6q+dpyENdEp+PUTN6+oNVLo0a6T?= =?us-ascii?Q?4qo6m/7CuPiFEYbytORVS2eQesVqgfnqSOTpT9hI+jhehrpk27SrYsEn3gmK?= =?us-ascii?Q?PGe4DSe4aXZzrl0pb5Rkyo6hcTQuzGC8Kps1yDUmM9n8ci4dxmzdy/ppSHMX?= =?us-ascii?Q?dmnHjBAHsmrbQ0+D8ZmX2l4YnBjxJ4ROZ/T7C+3xiUyfB7iKQAcubRXWjKLk?= =?us-ascii?Q?pBrk/jXA+5A093BYstm/zGDOcAaHZjE4pO8XQrCFn2Pyfbpt3CtmhRJOFZSO?= =?us-ascii?Q?FOE/Ap0Fh4nZeeWFhzIrGtgxZDxbdf73xrhJh1SmS6ikOVzB2Kf7e1/mSKFc?= =?us-ascii?Q?tIPNx/5rm5lG0BnCmPzFYQ1Jq/NuZvHCfiGtodkEDYPXwvmr2ZPDUBSCwPb8?= =?us-ascii?Q?ozjI+CkJVptoZ3fiq84dNMTLs7aeCbHWWC8RFhMqrbFd0+qDu/NP3UfslUKm?= =?us-ascii?Q?grLELOWca5QCNKbA62tJmHtN1Mwiwnj3qAvrAe7c+aG65Nq4nKtAd3mAQkZ4?= =?us-ascii?Q?VtgUbp6tg8uArIt9lne+O2VAgn0rwDislnaT1E4M4+NX8TsUp/GRQ=3D=3D?= X-Microsoft-Antispam-Message-Info: S+y7NZGBkVTevdooG7liL6WUzZg4HlOkr+bnwLkcTLZmAjnC5ZG7nqV/lZqimcMpNyfM3aLsP4fjkOsgE29JPhfS2akRZaLXjoCjgeAX3ajLrTrlQ0oSlHBHUyBBWvUPxe34W+HO+yScujZo588zt/VPVW4qxZM5+zQMEcQYvUo5YutlA7bEb/W0EK3Ketv6 X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3431; 6:2bHjzGWGue/DN5RZBtV5Olmb1IPvOca2blzMKQG6lP7XgSizaykor+u2qjT6qKnTdLg6vo0LmcJKrlB7lZKhwNqJr7STIGfWix39KpaNjvr0dar0MZLp1CMud6MJgAtO6rcnrGzIlPvWnVrvtOL1ObBNPGncP3CJqZBrpTE8+KG5n0Z0BFQow2JcJsTZ9LKMwIPKYCcXXZvatx00UOR5aTU4pBgh+3bTo8k31vkmpgNI3P96GvbTpdMLj+73tGmnxdLIZXb1gZfTjD2TldhhRaQTghejPAjoodlKuQEs6RxdW4gscv9TGQlSG3ObfFtgVgxFqRuWDLFrxDsO/vAwisP12p2x1HA4DTRjT6sW7rx47pbdy8uK7AvSnmN35Tmqn2OkQzaKQUWmFRiN0r3QkrPm+/CBApKASVo46DAUylhnh/a4j+ZziRzbPrandw9+mQOG0cCNt2PQhueAdP3PpQ==; 5:6RBj4d/KuEMqiEAb89S75AuD2MgC2vlJqFyCY3sIixjINT531EnkjyXJ3DgZng3eJesaPgOfnjvVdCsMxTutWUERkol1dS+T9/0tt4cUWQiJdGtFtF0a4mqtSGx/317WeamIvvPKCJQx3aZJ2lZ0NUZY+keFnb/+dUcYCqeCAwY=; 24:rnL7N0KF9104fhfXbobbIKr0tguLQqSQ6sB/YzIwP+0omtqJq9fftJEYkPS5Wp8XxfKaJQCOnDQNOht0cHEMLSEn7gqNNTLt/7XguUfF24c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3431; 7:dA3jNt9yY+hFkzIWVDUgfbagFA2vZbZx5sCIts1WnYF0HydYApd0vgQR0/rf9pP4LsatTWVQNWX2SHeK0fH5MheOMbAPsdFPL78D7oXlOR/gvhF5wbhiGdHtoJU4vdqmqT0iPRuJEN9TIf1iYbIVfxIX6OHm4SzT3SoIBKRPfZuPEueYEjeXJYDDhjvJFCjahITA6txpfWHp9fjtZ/lLSQ/kYCqYVjF8AY2JS4UbhWAoFCZn4R/RFXXsZ2mmME3l X-MS-Office365-Filtering-Correlation-Id: 43ed6615-b5db-49a6-8ba1-08d5cafbd2e3 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2018 15:48:45.5955 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 43ed6615-b5db-49a6-8ba1-08d5cafbd2e3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR05MB3431 Subject: [dpdk-dev] [RFC] ethdev: support tunnel encapsulation action 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: Tue, 05 Jun 2018 15:48:50 -0000 This RFC contain proposal to add generic support for tunnel encapsulation/decapsulation. Due to the fact that there are many possible tunnel types and each tunnel type has number of header variations, there is a need for some generic command. example for tunnel headers in case of MPLSoGRE: ETH / VLAN / IPV4 / GRE / MPLS / ETH / IP / L4-L7 ETH / VLAN / IPV6 / GRE / MPLS / ETH / IP / L4-L7 ETH / IPV4 / GRE / MPLS / ETH / IP / L4-L7 ETH / IPV6 / GRE / MPLS / ETH / IP / L4-L7 ETH / VLAN / IPV4 / GRE / MPLS / IP / L4-L7 ETH / VLAN / IPV6 / GRE / MPLS / IP / L4-L7 ETH / IPV4 / GRE / MPLS / IP / L4-L7 ETH / IPV6 / GRE / MPLS / IP / L4-L7 As can be seen from the examples some of the encapsulation is done by overwriting the inner L2 packet spec. To support all of those configuration it is much easer if we create 2 encap functions one that is used to encap L2 packet and one that is used to encap L3 packet by removing the L2 and applying the encapsulation header. The use of void * buffer will enable the insertion of any valid encapsulation header. the use of such a buffer will also simplify the processing needed to validate and apply vs the use of rte_flow_items. The use of a buffer will also will be easer for some applications (for example vrouter) For decap we will also have 2 actions one for decaping a packet with inner L2 and one for decaping a packet with inner L3. when decaping L3 packet the user should supplay the L2 data which should be added to the inner packet. Signed-off-by: Ori Kam --- doc/guides/prog_guide/rte_flow.rst | 141 ++++++++++++++----------------- lib/librte_ethdev/rte_flow.h | 165 +++++++++++++++++++++-------------- 2 files changed, 161 insertions(+), 145 deletions(-) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index b305a72..7417833 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1969,112 +1969,95 @@ Implements ``OFPAT_PUSH_MPLS`` ("push a new MPLS tag") as defined by the | ``ethertype`` | EtherType | +---------------+-----------+ -Action: ``VXLAN_ENCAP`` -^^^^^^^^^^^^^^^^^^^^^^^ - -Performs a VXLAN encapsulation action by encapsulating the matched flow in the -VXLAN tunnel as defined in the``rte_flow_action_vxlan_encap`` flow items -definition. +Action: ``TUNNEL_ENCAP`` +^^^^^^^^^^^^^^^^^^^^^^^^ -This action modifies the payload of matched flows. The flow definition specified -in the ``rte_flow_action_tunnel_encap`` action structure must define a valid -VLXAN network overlay which conforms with RFC 7348 (Virtual eXtensible Local -Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks -over Layer 3 Networks). The pattern must be terminated with the -RTE_FLOW_ITEM_TYPE_END item type. +Perform a tunnel encapsulation action by encapsulating the matched flow with +the given buffer. -.. _table_rte_flow_action_vxlan_encap: +This action modifies the payload of the matched flows. +The buffer must hold a valid tunnel encapsulation header. -.. table:: VXLAN_ENCAP +.. _table_rte_flow_action_tunnel_encap: +.. table:: TUNNEL_ENCAP + +----------------+-------------------------------------+ | Field | Value | +================+=====================================+ - | ``definition`` | Tunnel end-point overlay definition | + | ``type`` | Encapsulation tunnel type. | + +----------------+-------------------------------------+ + | ``buf`` | The encapsulation header. | + +----------------+-------------------------------------+ + | ``len`` | Buf len. | +----------------+-------------------------------------+ -.. _table_rte_flow_action_vxlan_encap_example: - -.. table:: IPv4 VxLAN flow pattern example. - - +-------+----------+ - | Index | Item | - +=======+==========+ - | 0 | Ethernet | - +-------+----------+ - | 1 | IPv4 | - +-------+----------+ - | 2 | UDP | - +-------+----------+ - | 3 | VXLAN | - +-------+----------+ - | 4 | END | - +-------+----------+ - -Action: ``VXLAN_DECAP`` -^^^^^^^^^^^^^^^^^^^^^^^ +Action: ``TUNNEL_DECAP`` +^^^^^^^^^^^^^^^^^^^^^^^^ -Performs a decapsulation action by stripping all headers of the VXLAN tunnel -network overlay from the matched flow. +Perform a tunnel decapsulation on L2 inner packet -The flow items pattern defined for the flow rule with which a ``VXLAN_DECAP`` -action is specified, must define a valid VXLAN tunnel as per RFC7348. If the -flow pattern does not specify a valid VXLAN tunnel then a -RTE_FLOW_ERROR_TYPE_ACTION error should be returned. +This action modifies the payload of the matched flows. +The buffer must hold a valid tunnel encapsulation header. -This action modifies the payload of matched flows. +.. _table_rte_flow_action_tunnel_decap: -Action: ``NVGRE_ENCAP`` -^^^^^^^^^^^^^^^^^^^^^^^ +.. table:: TUNNEL_DECAP + + +----------------+-------------------------------------+ + | Field | Value | + +================+=====================================+ + | ``type`` | Encapsulation tunnel type. | + +----------------+-------------------------------------+ -Performs a NVGRE encapsulation action by encapsulating the matched flow in the -NVGRE tunnel as defined in the``rte_flow_action_tunnel_encap`` flow item -definition. +Action: ``TUNNEL_ENCAP_L3`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This action modifies the payload of matched flows. The flow definition specified -in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid -NVGRE network overlay which conforms with RFC 7637 (NVGRE: Network -Virtualization Using Generic Routing Encapsulation). The pattern must be -terminated with the RTE_FLOW_ITEM_TYPE_END item type. +Perform a tunnel encapsulation action by encapsulating the matched flow with +the given buffer. +The given encapsulation is overwritten the original L2 part of the original +packet. -.. _table_rte_flow_action_nvgre_encap: +This action modifies the payload of the matched flows. The buffer must hold +a valid tunnel encapsulation header. -.. table:: NVGRE_ENCAP +.. _table_rte_flow_action_tunnel_encap_l3: +.. table:: TUNNEL_ENCAP_L3 + +----------------+-------------------------------------+ | Field | Value | +================+=====================================+ - | ``definition`` | NVGRE end-point overlay definition | + | ``type`` | Encapsulation tunnel type. | + +----------------+-------------------------------------+ + | ``buf`` | The encapsulation header. | + +----------------+-------------------------------------+ + | ``len`` | Buf len. | +----------------+-------------------------------------+ -.. _table_rte_flow_action_nvgre_encap_example: - -.. table:: IPv4 NVGRE flow pattern example. - - +-------+----------+ - | Index | Item | - +=======+==========+ - | 0 | Ethernet | - +-------+----------+ - | 1 | IPv4 | - +-------+----------+ - | 2 | NVGRE | - +-------+----------+ - | 3 | END | - +-------+----------+ +Action: ``TUNNEL_DECAP_L3`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Action: ``NVGRE_DECAP`` -^^^^^^^^^^^^^^^^^^^^^^^ +Perform a tunnel decapsulation action by removing the encapsulating packet header +and adding the L2 header which is suplied in the buf parameter. -Performs a decapsulation action by stripping all headers of the NVGRE tunnel -network overlay from the matched flow. +This action modifies the payload of the matched flows. +The buffer must hold a valid L2 header and the flow must match patteran with the +selected tunnel type. -The flow items pattern defined for the flow rule with which a ``NVGRE_DECAP`` -action is specified, must define a valid NVGRE tunnel as per RFC7637. If the -flow pattern does not specify a valid NVGRE tunnel then a -RTE_FLOW_ERROR_TYPE_ACTION error should be returned. +.. _table_rte_flow_action_tunnel_decap_l3: -This action modifies the payload of matched flows. +.. table:: TUNNEL_DECAP_L3 + + +----------------+-------------------------------------+ + | Field | Value | + +================+=====================================+ + | ``type`` | Encapsulation tunnel type. | + +----------------+-------------------------------------+ + | ``buf`` | The encapsulation header. | + +----------------+-------------------------------------+ + | ``len`` | Buf len. | + +----------------+-------------------------------------+ Negative types ~~~~~~~~~~~~~~ diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h index f8ba71c..cc01786 100644 --- a/lib/librte_ethdev/rte_flow.h +++ b/lib/librte_ethdev/rte_flow.h @@ -1473,40 +1473,74 @@ 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. + * Encapsulte a packet with tunnel header. + * + * See struct rte_flow_action_tunnel_encap. + */ + RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, + + /** + * Encapsulte a packet with tunnel header replacing + * the inner L2 data. + * + * See struct rte_flow_action_tunnel_encap_l3. + */ + RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP_L3, + + /** + * Decapsulate outer most tunnel from matched flow. * - * See struct rte_flow_action_vxlan_encap. + * If flow pattern does not define a valid tunnel then + * the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION + * error. */ - RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, /** - * Decapsulate outer most VXLAN tunnel from matched flow. + * Decapsulate outer most tunnel from matched flow and replace + * the L2 header with the new header. + * Valid header must be L2 only. * - * 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 + * If flow pattern does not define a valid tunnel then + * the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION * error. + * + * See struct rte_flow_action_tunnel_decap_l3 */ - RTE_FLOW_ACTION_TYPE_VXLAN_DECAP, + RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP_L3, +}; +enum rte_flow_tunnel_type { /** - * Encapsulate flow in NVGRE tunnel defined in the - * rte_flow_action_nvgre_encap action structure. - * - * See struct rte_flow_action_nvgre_encap. + * VXLAN tunnel type. */ - RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP, + RTE_FLOW_TUNNEL_TYPE_VXLAN, /** - * Decapsulate outer most NVGRE tunnel from matched flow. - * - * 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. + * VXLAN_GPE tunnel type. */ - RTE_FLOW_ACTION_TYPE_NVGRE_DECAP, -}; + RTE_FLOW_TUNNEL_TYPE_VXLAN_GPE, + /** + * MPLSoGRE tunnel type. + */ + RTE_FLOW_TUNNEL_TYPE_MPLSoGRE, + + /** + * MPLSoUDP tunnel type. + */ + RTE_FLOW_TUNNEL_TYPE_MPLSoUDP, + + /** + * NVGRE tunnel type. + */ + RTE_FLOW_TUNNEL_TYPE_NVGRE, + + /** + * GRE tunnel type. + */ + RTE_FLOW_TUNNEL_TYPE_GRE, +}; /** * RTE_FLOW_ACTION_TYPE_MARK * @@ -1526,7 +1560,7 @@ struct rte_flow_action_mark { * @b EXPERIMENTAL: this structure may change without prior notice * * RTE_FLOW_ACTION_TYPE_JUMP - * + o* * Redirects packets to a group on the current device. * * In a hierarchy of groups, which can be used to represent physical or logical @@ -1803,69 +1837,68 @@ 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 + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP * - * 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. + * Tunnel end-point encapsulation data definition. * - * 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. - * - * Note: the last field is not used in the definition of a tunnel and can be - * ignored. + * The tunnel definition is provided through the use of buffer that + * holds the encapsulating header. + * Provided header must be a valid outer tunnel header. + */ +struct rte_flow_action_tunnel_encap { + enum rte_flow_tunnel_type type; /**< The tunnel type. */ + void *buf; /**< The header to be used. */ + uint32_t len; /**< The buf len. */ +}; + +/** + * @warning + * @b EXPERIMENTAL: this structure may change without prior notice * - * Valid flow definition for RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP include: + * RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP * - * - ETH / IPV4 / UDP / VXLAN / END - * - ETH / IPV6 / UDP / VXLAN / END - * - ETH / VLAN / IPV4 / UDP / VXLAN / END + * Tunnel end-point dencapsulation data definition. * + * The tunnel type must match the flow rule spec. */ -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_decap { + enum rte_flow_tunnel_type type; /**< The tunnel type. */ }; /** * @warning * @b EXPERIMENTAL: this structure may change without prior notice * - * RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP - * - * NVGRE tunnel end-point encapsulation data definition - * - * 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. + * RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP_L3 * - * 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. + * Tunnel end-point encapsulation over the inner L2 data definition. * - * Note: the last field is not used in the definition of a tunnel and can be - * ignored. + * The tunnel definition is provided through the use of buffer that + * holds the encapsulating header. + * Provided header must be a valid outer tunnel header. + */ +struct rte_flow_action_tunnel_encap_l3 { + enum rte_flow_tunnel_type type; /**< The tunnel type. */ + void *buf; /**< The header to be used. */ + uint32_t len; /**< The buf len. */ +}; + +/** + * @warning + * @b EXPERIMENTAL: this structure may change without prior notice * - * Valid flow definition for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include: + * RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP_L3 * - * - ETH / IPV4 / NVGRE / END - * - ETH / VLAN / IPV6 / NVGRE / END + * Tunnel end-point dencapsulation data definition. + * after the decapsulation, the L2 of the resulted packet + * is replaced with the supplied buffer. * + * The tunnel type must match the flow rule spec. */ -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 { + enum rte_flow_tunnel_type type; /**< The tunnel type. */ + void *buf; /**< The L2 header to be used.*/ + uint32_t len; /**< The len of the buf. */ }; /* -- 1.7.1