[dpdk-dev] [PATCH v7 0/4] ethdev: add shared counter support to rte_flow
Ferruh Yigit
ferruh.yigit at intel.com
Thu Apr 26 22:58:47 CEST 2018
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.
More information about the dev
mailing list