On 4/26/2018 6:29 PM, Declan Doherty wrote: > This patchset contains the revised proposal to manage > tunnel endpoints 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. > > V3: > - Extended the descriptio:wn of group counter in documentation. > - Renamed VTEP to TUNNEL. > - Fixed C99 syntax. > > V4: > - Modify encap/decap actions to be protocol specific > - rename group action type to jump > - add mark flow item type in place of metadata flow/action types > - add count action data structure > - modify query API to accept rte_flow_action structure in place of > rte_flow_actio_type enumeration to support specification and > querying of multiple actions of the same type > > V5: > - Documentation and comment updates > - Mark new API structures as experimental > - squash new function testpmd enablement into relevant patches. > > V6: > - rebased to head of next-net > - fixed whitespace issues add in previous revision > > V7: > - fix mlx5 compliation issue due to change in flow query API > > The summary of the additions to the rte_flow are as follows: > > - Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP and > RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP to rte_flow to support > specfication of encapsulation and decapsulation of VXLAN and NVGRE > tunnels in hardware. > - Introduces support for the use of pipeline metadata in > the flow pattern definition and the population of metadata fields > from flow actions using the MARK flow and action items. > - Add shared flag to counters to enable statistics to be kept on > groups offlows such as all ingress/egress flows of a tunnel > - Adds jump_action to allow a flows to be redirected to a group > within the device. > > A high level summary of the proposed usage model is as follows: > > 1. Decapsulation > > 1.1. Decapsulation of tunnel 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_VXLAN_DECAP }, > { .type = RTE_FLOW_ACTION_TYPE_VF, .conf = &vf_action }, > { .type = RTE_FLOW_ACTION_TYPE_END } > } > > 1.2. > > Decapsulation of tunnel 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 tunnel > 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_item_count shared_couter = { > .shared = 1, > .id = {counter_id} > } > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &shared_counter }, > { .type = RTE_FLOW_ACTION_TYPE_MARK, .conf = &mark_action }, > { .type = RTE_FLOW_ACTION_TYPE_VXLAN_DECAP }, > { > .type = RTE_FLOW_ACTION_TYPE_JUMP, > .conf = { .group = 1 } > }, > { .type = RTE_FLOW_ACTION_TYPE_END } > } > > flow rule for inner header on table 1 > > struct rte_flow_attr attr = { .ingress = 1, .group = 1 }; > > struct rte_flow_item_mark mark_item = { id = {mark_id} }; > > struct rte_flow_item pattern[] = { > { .type = RTE_FLOW_ITEM_TYPE_MARK, .spec = &mark_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 mark action in the flow rule in group 0 is generating > the value in the pipeline which is then used in as part as the flow > pattern in group 1 to specify the exact flow to match against. In the > case where exact match rules are being provided by the application > explicitly then the MARK item value can be provided by the application > in the flow pattern for the flow rule in group 1 also. > > 2. Encapsulation > > Encapsulation of all traffic matching a specific flow pattern to a > specified tunnel 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_tunnel_encap vxlan_encap_action = { > .definition = { > { .type=eth, .spec={}, .mask={} }, > { .type=ipv4, .spec={}, .mask={} }, > { .type=udp, .spec={}, .mask={} }, > { .type=vxlan, .spec={}, .mask={} } > { .type=end } > } > }; > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_COUNT, .conf = &count } }, > { .type = RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP, .conf = &vxlan_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 tunnel encap/decap actions > ethdev: Add group JUMP action > ethdev: add mark flow item to rte_flow_item_types > ethdev: add shared counter support to rte_flow
Series applied to dpdk-next-net/master, thanks.
