From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id D64E3AA9E for ; 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 , dev@dpdk.org Cc: Alex Rosenbaum , Thomas Monjalon , Shahaf Shuler , Qi Zhang , Alejandro Lucero , Andrew Rybchenko , Mohammad Abdul Awal , Remy Horton , John McNamara , Rony Efraim , Jingjing Wu , Wenzhuo Lu , Vincent Jardin , Yuanhan Liu , Bruce Richardson , Konstantin Ananyev References: <20180418210423.13847-1-declan.doherty@intel.com> <20180423155620.22409-1-declan.doherty@intel.com> From: Ferruh Yigit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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