DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Declan Doherty <declan.doherty@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v7 0/4] ethdev: add shared counter support to rte_flow
Date: Thu, 26 Apr 2018 21:58:47 +0100	[thread overview]
Message-ID: <f481414a-1af2-1b05-eeb7-070f3c63dc86@intel.com> (raw)
In-Reply-To: <20180426172919.8450-1-declan.doherty@intel.com>

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

Series applied to dpdk-next-net/master, thanks.

  parent reply	other threads:[~2018-04-26 20:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 12:08 [dpdk-dev] [PATCH v6 0/4] additions to support tunnel encap/decap Declan Doherty
2018-04-26 12:08 ` [dpdk-dev] [PATCH v6 1/4] ethdev: Add tunnel encap/decap actions Declan Doherty
2018-04-26 12:08 ` [dpdk-dev] [PATCH v6 2/4] ethdev: Add group JUMP action Declan Doherty
2018-04-26 12:08 ` [dpdk-dev] [PATCH v6 3/4] ethdev: add mark flow item to rte_flow_item_types Declan Doherty
2018-04-26 12:08 ` [dpdk-dev] [PATCH v6 4/4] ethdev: add shared counter support to rte_flow Declan Doherty
2018-04-26 14:06   ` Ori Kam
2018-04-26 14:27     ` Ferruh Yigit
2018-04-26 14:43       ` Ori Kam
2018-04-26 14:48         ` Doherty, Declan
2018-04-26 17:29 ` [dpdk-dev] [PATCH v7 0/4] " Declan Doherty
2018-04-26 17:29   ` [dpdk-dev] [PATCH v7 1/4] ethdev: Add tunnel encap/decap actions Declan Doherty
2018-04-26 17:29   ` [dpdk-dev] [PATCH v7 2/4] ethdev: Add group JUMP action Declan Doherty
2018-04-26 18:54     ` Thomas Monjalon
2018-04-27 12:24       ` Ferruh Yigit
2018-04-26 17:29   ` [dpdk-dev] [PATCH v7 3/4] ethdev: add mark flow item to rte_flow_item_types Declan Doherty
2018-04-26 18:52     ` Thomas Monjalon
2018-04-27 12:24       ` Ferruh Yigit
2018-04-26 17:29   ` [dpdk-dev] [PATCH v7 4/4] ethdev: add shared counter support to rte_flow Declan Doherty
2018-04-26 18:55     ` Thomas Monjalon
2018-04-27 12:25       ` Ferruh Yigit
2018-04-27 14:52         ` Ferruh Yigit
2018-04-26 20:58   ` Ferruh Yigit [this message]
2018-04-27 20:18 ` [dpdk-dev] [PATCH v6 0/4] additions to support tunnel encap/decap Michael Wildt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f481414a-1af2-1b05-eeb7-070f3c63dc86@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).