Re: [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 4/23/2018 4:56 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 description 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.
> 
> 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 = &eth_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 = &eth_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 = &eth_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 = &eth_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

Hi Declan,

Can you please rebase this set on latest next-net, updates done to
rte_flow_query() in this set causing build errors in bonding rte_flow, that
needs to be updated as well.

Also rte_flow.rst is giving build warnings, can you please check document build?

Thanks,
ferruh