DPDK patches and discussions
 help / color / mirror / Atom feed
From: Declan Doherty <declan.doherty@intel.com>
To: dev@dpdk.org
Cc: Alex Rosenbaum <alexr@mellanox.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Qi Zhang <qi.z.zhang@intel.com>,
	Alejandro Lucero <alejandro.lucero@netronome.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>,
	Remy Horton <remy.horton@intel.com>,
	John McNamara <john.mcnamara@intel.com>,
	Rony Efraim <ronye@mellanox.com>,
	Jingjing Wu <jingjing.wu@intel.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Vincent Jardin <vincent.jardin@6wind.com>,
	Yuanhan Liu <yliu@fridaylinux.org>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Zhihong Wang <zhihong.wang@intel.com>,
	Declan Doherty <declan.doherty@intel.com>
Subject: [dpdk-dev] [PATCH v4 0/6] additions to support tunnel encap/decap
Date: Wed, 18 Apr 2018 22:04:17 +0100	[thread overview]
Message-ID: <20180418210423.13847-1-declan.doherty@intel.com> (raw)
In-Reply-To: <1523017443-12414-1-git-send-email-declan.doherty@intel.com>

This patchset contains the revised proposal to manage virtual
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


The summary of the additions to the rte_flow are as follows:

- Add new flow actions RTE_RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP and
RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP to rte_flow to support specfication
of encapsulation and decapsulation of virtual Tunnel Endpoint on
hardware.

- Updates the matching pattern item definition
description to specify that all actions which modify a packet
must be specified in the explicit order they are to be excuted.

- Introduces support for the use of pipeline metadata in
the flow pattern definition and the population of metadata fields
from flow actions.

- Adds group counters to enable statistics to be kept on groups of
flows such as all ingress/egress flows of a tunnel

- Adds group_action to allow a flow termination to be a group/table
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_TUNNEL_DECAP, .type = VxLAN },
	{ .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 = {}
}

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, .table = 1 };

struct rte_flow_item_mark mark_item = { id = X };

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 metadata action in the flow rule in table 0 is generating
the metadata in the pipeline which is then used in as part as the flow
pattern in table 1 to specify the exact flow to match against. In the
case where exact match rules are being provided by the application
then this metadata could be extracted by the PMD from the flow pattern
for the group 0 rule, the matching metadata will then need to be
explicitly provided by the application in the flow pattern for the flow
rule in group 1. For devices capable of wildcard matching then the hardware
must be capable of extracting the data from the packet as specified by the
mask in the flow action rule in group 0.

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 (6):
  ethdev: Add tunnel encap/decap actions
  ethdev: Add group action type to rte_flow
  testpmd: add jump action
  ethdev: add mark flow item to rte_flow_item_types
  testpmd: add support for MARK flow item
  ethdev: add shared counter support to rte_flow

 app/test-pmd/cmdline_flow.c                 |  51 +++++++-
 app/test-pmd/config.c                       |  15 ++-
 app/test-pmd/testpmd.h                      |   2 +-
 doc/guides/prog_guide/rte_flow.rst          | 191 +++++++++++++++++++++++++---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |   8 ++
 drivers/net/failsafe/failsafe_flow.c        |   4 +-
 lib/librte_ether/rte_flow.c                 |   2 +-
 lib/librte_ether/rte_flow.h                 | 148 ++++++++++++++++++++-
 lib/librte_ether/rte_flow_driver.h          |   2 +-
 9 files changed, 384 insertions(+), 39 deletions(-)

-- 
2.14.3

  parent reply	other threads:[~2018-04-18 21:13 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 12:23 [dpdk-dev] [PATCH v3 0/4] ethdev: Additions to support tunnel encap/decap offload Declan Doherty
2018-04-06 12:24 ` [dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow Declan Doherty
2018-04-06 20:26   ` Adrien Mazarguil
2018-04-09 14:22     ` Mohammad Abdul Awal
2018-04-09 15:23       ` Adrien Mazarguil
2018-04-06 12:24 ` [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions Declan Doherty
2018-04-06 20:26   ` Adrien Mazarguil
2018-04-09 16:10     ` Mohammad Abdul Awal
2018-04-10 10:19       ` Adrien Mazarguil
2018-04-10 11:06         ` Shahaf Shuler
2018-04-17 14:58     ` Doherty, Declan
2018-04-06 12:24 ` [dpdk-dev] [PATCH v3 3/4] ethdev: Add group action type to rte_flow Declan Doherty
2018-04-06 20:26   ` Adrien Mazarguil
2018-04-17 14:40     ` Doherty, Declan
2018-04-06 12:24 ` [dpdk-dev] [PATCH v3 4/4] ethdev: Add metadata flow and action items support Declan Doherty
2018-04-06 20:27   ` Adrien Mazarguil
2018-04-17 14:40     ` Doherty, Declan
2018-04-27  7:41   ` Xueming(Steven) Li
2018-04-18 21:04 ` Declan Doherty [this message]
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 1/6] ethdev: Add tunnel encap/decap actions Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-23 11:00       ` Shahaf Shuler
2018-04-23 11:17         ` Doherty, Declan
2018-04-23 11:49           ` Adrien Mazarguil
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 2/6] ethdev: Add jump action type to rte_flow Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 3/6] testpmd: add jump action Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 4/6] ethdev: add mark flow item to flow item types Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-23 11:10       ` Shahaf Shuler
2018-04-23 11:49         ` Adrien Mazarguil
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 5/6] testpmd: add support for MARK flow item Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-18 21:04   ` [dpdk-dev] [PATCH v4 6/6] ethdev: add shared counter support to rte_flow Declan Doherty
2018-04-19 13:03     ` Adrien Mazarguil
2018-04-23 11:11   ` [dpdk-dev] [PATCH v4 0/6] additions to support tunnel encap/decap Shahaf Shuler
2018-04-23 11:13     ` Doherty, Declan
2018-04-23 15:56   ` [dpdk-dev] [PATCH v5 0/4] ethdev " Declan Doherty
2018-04-23 15:56     ` [dpdk-dev] [PATCH v5 1/4] ethdev: Add tunnel encap/decap actions Declan Doherty
2018-04-23 15:56     ` [dpdk-dev] [PATCH v5 2/4] ethdev: Add group JUMP action Declan Doherty
2018-04-23 15:56     ` [dpdk-dev] [PATCH v5 3/4] ethdev: add mark flow item to rte_flow_item_types Declan Doherty
2018-04-23 15:56     ` [dpdk-dev] [PATCH v5 4/4] ethdev: add shared counter support to rte_flow Declan Doherty
2018-04-24 16:26     ` [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel encap/decap Thomas Monjalon
2018-04-30 13:54       ` Thomas Monjalon
2018-04-25 22:05     ` Ferruh Yigit

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=20180418210423.13847-1-declan.doherty@intel.com \
    --to=declan.doherty@intel.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=alexr@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mohammad.abdul.awal@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=remy.horton@intel.com \
    --cc=ronye@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=vincent.jardin@6wind.com \
    --cc=wenzhuo.lu@intel.com \
    --cc=yliu@fridaylinux.org \
    --cc=zhihong.wang@intel.com \
    /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).