From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id AB4AB1CBAD for ; Thu, 5 Apr 2018 16:00:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2018 07:00:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,411,1517904000"; d="scan'208";a="214177474" Received: from dwdohert-ws.ir.intel.com ([163.33.210.60]) by orsmga005.jf.intel.com with ESMTP; 05 Apr 2018 07:00:05 -0700 From: Declan Doherty To: dev@dpdk.org Cc: Alex Rosenbaum , Ferruh Yigit , Thomas Monjalon , Shahaf Shuler , Qi Zhang , Alejandro Lucero , Andrew Rybchenko , Mohammad Abdul Awal , Remy Horton , John McNamara , Rony Efraim , Jingjing Wu , Wenzhuo Lu , Yuanhan Liu , Bruce Richardson , Declan Doherty Date: Thu, 5 Apr 2018 14:51:44 +0100 Message-Id: <20180405135148.16388-1-declan.doherty@intel.com> X-Mailer: git-send-email 2.14.3 Subject: [dpdk-dev] [PATCH v2 0/4] ethdev: Additions to support vTEP encap/decap offload 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: Thu, 05 Apr 2018 14:00:11 -0000 This patchset contains the revised proposal to manage virtual tunnel endpoints (vTEP) hardware accleration based on community feedback on RFC (http://dpdk.org/ml/archives/dev/2017-December/084676.html). This proposal is purely enabled through rte_flow APIs with the additions of some new features which were previously implemented by the proposed rte_tep APIs which were proposed in the original RFC. This patchset ultimately aims to enable the configuration of inline data path encapsulation and decapsulation of tunnel endpoint network overlays on accelerated IO devices. V2: Split new functions into separate patches, and add additional documentaiton. The summary of the additions to the rte_flow are as follows: - Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_VTEP_ENCAP and RTE_FLOW_ACTION_TYPE_VTEP_DECAP to rte_flow to support specfication of encapsulation and decapsulation of virtual Tunnel Endpoint on hardware. - Updates the matching pattern item definition description to specify that all actions which modify a packet must be specified in the explicit order they are to be excuted. - Introduces support for the use of pipeline metadata in the flow pattern defintion and the population of metadata fields from flow actions. - Adds group counters to enable statistics to be kept on groups of flows such as all ingress/egress flows of a vTEP - Adds group_action to allow a flow termination to be a group/table within the device. A high level summary of the proposed usage model is as follows: 1. Decapsulation 1.1. Decapsulation of vTEP outer headers and forward all traffic to the same queue/s or port, would have the follow flows paramteters, sudo code used here. struct rte_flow_attr attr = { .ingress = 1 }; struct rte_flow_item pattern[] = { { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = ð_item }, { .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item }, { .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item }, { .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item }, { .type = RTE_FLOW_ITEM_TYPE_END } }; struct rte_flow_action actions[] = { { .type = RTE_FLOW_ACTION_TYPE_VTEP_DECAP, .type = VxLAN }, { .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action }, { .type = RTE_FLOW_ACTION_TYPE_END } } 1.2. Decapsulation of vTEP outer headers and matching on inner headers, and forwarding to the same queue/s or port. 1.2.1. The same scenario as above but either the application or hardware requires configuration as 2 logically independent operations (viewing it as 2 logical tables). The first stage being the flow rule to define the pattern to match the vTEP and the action to decapsulate the packet, and the second stage stage table matches the inner header and defines the actions, forward to port etc. flow rule for outer header on table 0 struct rte_flow_attr attr = { .ingress = 1, .table = 0 }; struct rte_flow_item pattern[] = { { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = ð_item }, { .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item }, { .type = RTE_FLOW_ITEM_TYPE_UDP, .spec = &udp_item }, { .type = RTE_FLOW_ITEM_TYPE_VxLAN, .spec = &vxlan_item }, { .type = RTE_FLOW_ITEM_TYPE_END } }; struct rte_flow_action actions[] = { { .type = RTE_FLOW_ACTION_TYPE_GROUP_COUNT, .conf = &vtep_counter }, { .type = RTE_FLOW_ACTION_TYPE_METADATA, .conf = &metadata_action }, { .type = RTE_FLOW_ACTION_TYPE_VTEP_DECAP, .conf = VxLAN }, { .type = RTE_FLOW_ACTION_TYPE_GROUP, .conf = &group_action = { .id = 1 } }, { .type = RTE_FLOW_ACTION_TYPE_END } } flow rule for inner header on table 1 struct rte_flow_attr attr = { .ingress = 1, .table = 1 }; struct rte_flow_item pattern[] = { { .type = RTE_FLOW_ITEM_TYPE_METADATA, .spec = &metadata_item }, { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = ð_item }, { .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item }, { .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item }, { .type = RTE_FLOW_ITEM_TYPE_END } }; struct rte_flow_action actions[] = { { .type = RTE_FLOW_ACTION_TYPE_PORT_ID, .conf = &port_id_action = { port_id } }, { .type = RTE_FLOW_ACTION_TYPE_END } } Note that the metadata action in the flow rule in table 0 is generating the metadata in the pipeline which is then used in as part as the flow pattern in table 1 to specify the exact flow to match against. In the case where exact match rules are being provided by the application then this metadata could be extracted by the PMD from the flow pattern for the group 0 rule, the matching metadata will then need to be explictly provided by the application in the flow pattern for the flow rule in group 1. For devices capable of wildcard matching then the hardware must be capable of extracting the data from the packet as specified by the mask in the flow action rule in group 0. 2. Encapsulation Encapsulation of all traffic matching a specific flow pattern to a specified vTEP and egressing to a particular port. struct rte_flow_attr attr = { .egress = 1 }; struct rte_flow_item pattern[] = { { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = ð_item }, { .type = RTE_FLOW_ITEM_TYPE_IPV4, .spec = &ipv4_item }, { .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &tcp_item }, { .type = RTE_FLOW_ITEM_TYPE_END } }; struct rte_flow_action_vtep_encap encap_action = { .patterns = { { .type=eth, .item = {} }, { .type=ipv4, .item = {} }, { .type=udp, .item = {} }, { .type=vxlan, .item = {} } } }; struct rte_flow_action actions[] = { { .type = RTE_FLOW_ACTION_TYPE_GROUP_COUNT, .conf = &group_count } }, { .type = RTE_FLOW_ACTION_TYPE_VTEP_ENCAP, .conf = &encap_action } }, { .type = RTE_FLOW_ACTION_TYPE_PORT_ID, .conf = &port_id_action = { port_id } }, { .type = RTE_FLOW_ACTION_TYPE_END } } Declan Doherty (4): ethdev: add group counter support to rte_flow ethdev: Add vTEP encap/decap actions ethdev: Add group action type to rte_flow ethdev: Add metadata flow and action items support doc/guides/prog_guide/rte_flow.rst | 218 +++++++++++++++++++++++++++++++- lib/librte_ether/rte_ethdev_version.map | 8 ++ lib/librte_ether/rte_flow.c | 21 +++ lib/librte_ether/rte_flow.h | 192 +++++++++++++++++++++++++++- lib/librte_ether/rte_flow_driver.h | 6 + 5 files changed, 439 insertions(+), 6 deletions(-) -- 2.14.3