[dpdk-dev] [PATCH v7 0/4] ethdev: add shared counter support to rte_flow

[Declan Doherty <declan.doherty@intel.com>]

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 = &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

 app/test-pmd/cmdline_flow.c                 |  51 +++++-
 app/test-pmd/config.c                       |  19 +-
 app/test-pmd/testpmd.h                      |   2 +-
 doc/guides/prog_guide/rte_flow.rst          | 257 ++++++++++++++++++++++++----
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   8 +
 drivers/net/bonding/rte_eth_bond_flow.c     |   9 +-
 drivers/net/failsafe/failsafe_flow.c        |   4 +-
 drivers/net/mlx5/mlx5.h                     |   2 +-
 drivers/net/mlx5/mlx5_flow.c                |   2 +-
 lib/librte_ether/rte_flow.c                 |   2 +-
 lib/librte_ether/rte_flow.h                 | 211 +++++++++++++++++++++--
 lib/librte_ether/rte_flow_driver.h          |   2 +-
 12 files changed, 504 insertions(+), 65 deletions(-)

-- 
2.14.3