From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by dpdk.org (Postfix) with ESMTP id D64E3AA9E
for <dev@dpdk.org>; Thu, 26 Apr 2018 00:05:43 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
25 Apr 2018 15:05:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.49,328,1520924400"; d="scan'208";a="223424400"
Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.252.11.8])
([10.252.11.8])
by fmsmga006.fm.intel.com with ESMTP; 25 Apr 2018 15:05:36 -0700
To: Declan Doherty <declan.doherty@intel.com>, dev@dpdk.org
Cc: Alex Rosenbaum <alexr@mellanox.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>
References: <20180418210423.13847-1-declan.doherty@intel.com>
<20180423155620.22409-1-declan.doherty@intel.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Openpgp: preference=signencrypt
Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata=
xsFNBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy
qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ
+iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9
GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb
+dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF
YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy
ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX
CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1
1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz
cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABzSVGZXJydWggWWln
aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+wsF+BBMBAgAoAhsDBgsJCAcDAgYVCAIJCgsE
FgIDAQIeAQIXgAUCWZR3VQUJB33WBQAKCRD5M+tD3xNhH6DWEACVhEb8q1epPwZrUDoxzu7E
TS1b8tmabOmnjXZRs6+EXgUVHkp2xxkCfDmL3pa5bC0G/74aJnWjNsdvE05V1cb4YK4kRQ62
FwDQ+hlrFrwFB3PtDZk1tpkzCRHvJgnIil+0MuEh32Y57ig6hy8yO8ql7Lohyrnpfk/nNpm4
jQGEF5qEeHcEFe1AZQlPHN/STno8NZSz2nl0b2cw+cujN1krmvB52Ah/2KugQ6pprVyrGrzB
c34ZQO9OsmSjJlETCZk6EZzuhfe16iqBFbOSadi9sPcJRwaUQBid+xdFWl7GQ8qC3zNPibSF
HmU43yBZUqJDZlhIcl6/cFpOSjv2sDWdtjEXTDn5y/0FsuY0mFE78ItC4kCTIVk17VZoywcd
fmbbnwOSWzDq7hiUYuQGkIudJw5k/A1CMsyLkoUEGN3sLfsw6KASgS4XrrmPO4UVr3mH5bP1
yC7i1OVNpzvOxtahmzm481ID8sk72GC2RktTOHb0cX+qdoiMMfYgo3wRRDYCBt6YoGYUxF1p
msjocXyqToKhhnFbXLaZlVfnQ9i2i8jsj9SKig+ewC2p3lkPj6ncye9q95bzhmUeJO6sFhJg
Hiz6syOMg8yCcq60j07airybAuHIDNFWk0gaWAmtHZxLObZx2PVn2nv9kLYGohFekw0AOsIW
ta++5m48dnCoAc7BTQRX1ky+ARAApzQNvXvE2q1LAS+Z+ni2R13Bb1cDS1ZYq1jgpR13+OKN
ipzd8MPngRJilXxBaPTErhgzR0vGcNTYhjGMSyFIHVOoBq1VbP1a0Fi/NqWzJOowo/fDfgVy
K4vuitc/gCJs+2se4hdZA4EQJxVlNM51lgYDNpjPGIA43MX15OLAip73+ho6NPBMuc5qse3X
pAClNhBKfENRCWN428pi3WVkT+ABRTE0taxjJNP7bb+9TQYNRqGwnGzX5/XISv44asWIQCaq
vOkXSUJLd//cdVNTqtL1wreCVVR5pMXj7VIrlk07fmmJVALCmGbFr53BMb8O+8dgK2A5mitM
n44d+8KdJWOwziRxcaMk/LclmZS3Iv1TERtiWt98Y9AjeAtcgYPkA3ld0BcUKONogP8pHVz1
Ed3s5rDQ91yr1S0wuAzW91fxGUO4wY+uPmxCtFVuBgd9VT9NAKTUL0qHM7CDgCnZPe0TW6Zj
8OqtdCCyAfvU9cW5xWM7Icxhde6AtPxhDSBwE8fL2ZmrDmaA4jmUKXp3i4JxRPSX84S08b+s
DWXHPxy10UFU5A7EK/BEbZAKBwn9ROfm+WK+6X5xOGLoRE++OqNuUudxC1GDyLOPaqCbBCS9
+P6HsTHzxsjyJa27n4jcrcuY3P9TEcFJYSZSeSDh8mVGvugi0exnSJrrBZDyVCcAEQEAAcLB
ZQQYAQIADwIbDAUCWZR1ZwUJA59cIQAKCRD5M+tD3xNhH5b+D/9XG44Ci6STdcA5RO/ur05J
EE3Ux1DCHZ5V7vNAtX/8Wg4l4GZfweauXwuJ1w7Sp7fklwcNC6wsceI+EmNjGMqfIaukGetG
+jBGqsQ7moOZodfXUoCK98gblKgt/BPYMVidzlGC8Q/+lZg1+o29sPnwImW+MXt/Z5az/Z17
Qc265g+p5cqJHzq6bpQdnF7Fu6btKU/kv6wJghENvgMXBuyThqsyFReJWFh2wfaKyuix3Zyj
ccq7/blkhzIKmtFWgDcgaSc2UAuJU+x9nuYjihW6WobpKP/nlUDu3BIsbIq09UEke+uE/QK+
FJ8PTJkAsXOf1Bc2C0XbW4Y2hf103+YY6L8weUCBsWC5VH5VtVmeuh26ENURclwfeXhWQ9Og
77yzpTXWr5g1Z0oLpYpWPv745J4bE7pv+dzxOrFdM1xNkzY2pvXph/A8OjxZNQklDkHQ7PIB
Lki5L2F4XkEOddUUQchJwzMqTPsggPDmGjgLZrqgO+s4ECZK5+nLD3HEpAbPa3JLDaScy+90
Nu1lAqPUHSnP3vYZVw85ZYm6UCxHE4VLMnnJsN09ZhsOSVR+GyP5Nyw9rT1V3lcsuH7M5Naa
2Xobn9m7l9bRCD/Ji8kG15eV1WTxx1HXVQGjdUYDI7UwegBNbwMLh17XDy+3sn/6SgcqtECA
Q6pZKA2mTQxEKMLBZQQYAQIADwIbDAUCWZR3hQUJA59eRwAKCRD5M+tD3xNhH4a/D/4jLAZu
UhvU1swWcNEVVCELZ0D3LOV14XcY2MXa3QOpeZ9Bgq7YYJ4S5YXK+SBQS0FkRZdjGNvlGZoG
ZdpU+NsQmQFhqHGwX0IT9MeTFM8uvKgxNKGwMVcV9g0IOqwBhGHne+BFboRA9362fgGW5AYQ
zT0mzzRKEoOh4r3AQvbM6kLISxo0k1ujdYiI5nj/5WoKDqxTwwfuN1uDUHsWo3tzenRmpMyU
NyW3Dc+1ajvXLyo09sRRq7BnM99Rix1EGL8Qhwy+j0YAv+FuspWxUX9FxXYho5PvGLHLsHfK
FYQ7x/RRbpMjkJWVfIe/xVnfvn4kz+MTA5yhvsuNi678fLwY9hBP0y4lO8Ob2IhEPdfnTuIs
tFVxXuelJ9xAe5TyqP0f+fQjf1ixsBZkqOohsBXDfje0iaUpYa/OQ/BBeej0dUdg2JEu4jAC
x41HpVCnP9ipLpD0fYz1d/dX0F/VY2ovW6Eba/y/ngOSAR6C+u881m7oH2l0G47MTwkaQCBA
bLGXPj4TCdX3lftqt4bcBPBJ+rFAnJmRHtUuyyaewBnZ81ZU2YAptqFM1kTh+aSvMvGhfVsQ
qZL2rk2OPN1hg+KXhErlbTZ6oPtLCFhSHQmuxQ4oc4U147wBTUuOdwNjtnNatUhRCp8POc+3
XphVR5G70mnca1E2vzC77z+XSlTyRA==
Message-ID: <969b7fb3-4a39-62df-0b41-f631a99a6b06@intel.com>
Date: Wed, 25 Apr 2018 23:05:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180423155620.22409-1-declan.doherty@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v5 0/4] ethdev additions to support tunnel
encap/decap
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2018 22:05:44 -0000
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 = ð_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
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