From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id AB92B1B317 for ; Tue, 13 Feb 2018 18:05:14 +0100 (CET) Received: by mail-wr0-f172.google.com with SMTP id o76so16190770wrb.7 for ; Tue, 13 Feb 2018 09:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+IldkY5EFievIAbgxIlfMk2E5bbh17yV3jeV/KbePaA=; b=usgN5ghhOypiUxfKf09HWC2JQvCHavouwHvfKlMJVONmK3oLWoITvfEXri59s4szTx H/1NjEZbhgZUjcTRovYkiKJEug+KERy2p0MDfld2PAJO5H6zfBJdO3ng/7FjjAzpK9GN SClOR46kf83k4fhJV+MF4LUYg0ISHhdA6Ty09l9CbWIlz2eHcU7PUReIDJTfqx3KUxM4 FCOW5vbLManehoN1TT8QoeaEO356pUqduHqBFjA+8ATEYnVcX3Dhz21NDV9nXZYMXqxi 2P42tHnb0IupyhQ1jtJD+iO+KbJCOugQsSHI6xVltxPobAXHsnGHC7NLQJQF7lzOmHEd reCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+IldkY5EFievIAbgxIlfMk2E5bbh17yV3jeV/KbePaA=; b=IkogocJGT0Alty5BBARjvkwIdhWAbWhcAmA6KXWO1FqKWXhveRB5FWp7i1UuE0gQ8R L0qR+xQUlterx35YmjDl21NrF/WVsygv/lZUH95JWIydGQ8WlPSK3lS+NkALDsAoDogc X6BxjNW51isd4J/ladhk7Cum4wLoWNcx/H3G+a2uW+hkwvI4PpT1rw8miK0BH5sp3neO Xl75L+oJhY8dXCoElF4hMSivwjHnWmlJiLWwhYKCdGf6FMd1icfWVH/Vuu+WS0dlIcr8 ss4XFwFfamarJrW4yQRsWVI7X+WKzYKcnP2xUyrCMgc8Pu3Yqbk73BefeTc/L3eQhcE5 XtIA== X-Gm-Message-State: APf1xPBtzZA7PRSJWfMtfEji7bVFvMRnEYQ9fPOkMfep7qFehlaNZ9zI W+Q9D2snEl/5RpiDvYMoMpzF1x/g X-Google-Smtp-Source: AH8x227mlDNYDTCf3emttTb2NUC0VW7X1WLP12HrpPIFKunT2+aRAJA6FBNJ4YlxfH4Cm/9S8EbWOQ== X-Received: by 10.223.172.116 with SMTP id v107mr1836698wrc.269.1518541514070; Tue, 13 Feb 2018 09:05:14 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b133sm7345100wmh.4.2018.02.13.09.05.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 09:05:12 -0800 (PST) Date: Tue, 13 Feb 2018 18:05:00 +0100 From: Adrien Mazarguil To: "Doherty, Declan" Cc: "dev@dpdk.org" , Shahaf Shuler , "John Daley (johndale)" , Boris Pismenny , Nelio Laranjeiro Message-ID: <20180213170500.GO4256@6wind.com> References: <345C63BAECC1AD42A2EC8C63AFFC3ADCC488E501@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <345C63BAECC1AD42A2EC8C63AFFC3ADCC488E501@IRSMSX102.ger.corp.intel.com> Subject: Re: [dpdk-dev] [RFC] tunnel endpoint hw acceleration enablement 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: Tue, 13 Feb 2018 17:05:14 -0000 Hi, Apologies for being late to this thread, I've read the ensuing discussion (hope I didn't miss any) and also think rte_flow could be improved in several ways to enable TEP support, in particular regarding the ordering of actions. On the other hand I'm not sure a dedicated API for TEP is needed at all. I'm not convinced rte_security chose the right path and would like to avoid repeating the same mistakes if possible, more below. On Thu, Dec 21, 2017 at 10:21:13PM +0000, Doherty, Declan wrote: > This RFC contains a proposal to add a new tunnel endpoint API to DPDK that when used > in conjunction with rte_flow enables the configuration of inline data path encapsulation > and decapsulation of tunnel endpoint network overlays on accelerated IO devices. > > The proposed new API would provide for the creation, destruction, and > monitoring of a tunnel endpoint in supporting hw, as well as capabilities APIs to allow the > acceleration features to be discovered by applications. > > /** Tunnel Endpoint context, opaque structure */ > struct rte_tep; > > enum rte_tep_type { > RTE_TEP_TYPE_VXLAN = 1, /**< VXLAN Protocol */ > RTE_TEP_TYPE_NVGRE, /**< NVGRE Protocol */ > ... > }; > > /** Tunnel Endpoint Attributes */ > struct rte_tep_attr { > enum rte_type_type type; > > /* other endpoint attributes here */ > } > > /** > * Create a tunnel end-point context as specified by the flow attribute and pattern > * > * @param port_id Port identifier of Ethernet device. > * @param attr Flow rule attributes. > * @param pattern Pattern specification by list of rte_flow_items. > * @return > * - On success returns pointer to TEP context > * - On failure returns NULL > */ > struct rte_tep *rte_tep_create(uint16_t port_id, > struct rte_tep_attr *attr, struct rte_flow_item pattern[]) > > /** > * Destroy an existing tunnel end-point context. All the end-points context > * will be destroyed, so all active flows using tep should be freed before > * destroying context. > * @param port_id Port identifier of Ethernet device. > * @param tep Tunnel endpoint context > * @return > * - On success returns 0 > * - On failure returns 1 > */ > int rte_tep_destroy(uint16_t port_id, struct rte_tep *tep) > > /** > * Get tunnel endpoint statistics > * > * @param port_id Port identifier of Ethernet device. > * @param tep Tunnel endpoint context > * @param stats Tunnel endpoint statistics > * > * @return > * - On success returns 0 > * - On failure returns 1 > */ > Int > rte_tep_stats_get(uint16_t port_id, struct rte_tep *tep, > struct rte_tep_stats *stats) > > /** > * Get ports tunnel endpoint capabilities > * > * @param port_id Port identifier of Ethernet device. > * @param capabilities Tunnel endpoint capabilities > * > * @return > * - On success returns 0 > * - On failure returns 1 > */ > int > rte_tep_capabilities_get(uint16_t port_id, > struct rte_tep_capabilities *capabilities) > > > To direct traffic flows to hw terminated tunnel endpoint the rte_flow API is > enhanced to add a new flow item type. This contains a pointer to the > TEP context as well as the overlay flow id to which the traffic flow is > associated. > > struct rte_flow_item_tep { > struct rte_tep *tep; > uint32_t flow_id; > } What I dislike is rte_flow item/actions relying on externally-generated opaque objects when these can be avoided, as it means yet another API applications have to deal with and PMDs need to implement; this adds a layer of inefficiency in my opinion. I believe TEP can be fully implemented through a combination of new rte_flow pattern items/actions without involving external API calls. More on that later. > Also 2 new generic actions types are added encapsulation and decapsulation. > > RTE_FLOW_ACTION_TYPE_ENCAP > RTE_FLOW_ACTION_TYPE_DECAP > > struct rte_flow_action_encap { > struct rte_flow_item *item; > } > > struct rte_flow_action_decap { > struct rte_flow_item *item; > } Encap/decap actions are definitely needed and useful, no question about that. I'm unsure about doing so through a generic action with the described structures instead of dedicated ones though. These can't work with anything other than rte_flow_item_tep; a special pattern item using some kind of opaque object is needed (e.g. using rte_flow_item_tcp makes no sense with them). Also struct rte_flow_item is tailored for flow rule patterns, using it with actions is not only confusing, it makes its "mask" and "last" members useless and inconsistent with their documentation. Although I'm not convinced an opaque object is the right approach, if we choose this route I suggest the much simpler: struct rte_flow_action_tep_(encap|decap) { struct rte_tep *tep; uint32_t flow_id; }; > The following section outlines the intended usage of the new APIs and then how > they are combined with the existing rte_flow APIs. > > Tunnel endpoints are created on logical ports which support the capability > using rte_tep_create() using a combination of TEP attributes and > rte_flow_items. In the example below a new IPv4 VxLAN endpoint is being defined. > The attrs parameter sets the TEP type, and could be used for other possible > attributes. > > struct rte_tep_attr attrs = { .type = RTE_TEP_TYPE_VXLAN }; > > The values for the headers which make up the tunnel endpointr are then > defined using spec parameter in the rte flow items (IPv4, UDP and > VxLAN in this case) > > struct rte_flow_item_ipv4 ipv4_item = { > .hdr = { .src_addr = saddr, .dst_addr = daddr } > }; > > struct rte_flow_item_udp udp_item = { > .hdr = { .src_port = sport, .dst_port = dport } > }; > > struct rte_flow_item_vxlan vxlan_item = { .flags = vxlan_flags }; > > struct rte_flow_item pattern[] = { > { .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 } > }; > > The tunnel endpoint can then be create on the port. Whether or not any hw > configuration is required at this point would be hw dependent, but if not > the context for the TEP is available for use in programming flow, so the > application is not forced to redefine the TEP parameters on each flow > addition. > > struct rte_tep *tep = rte_tep_create(port_id, &attrs, pattern); > > Once the tep context is created flows can then be directed to that endpoint for > processing. The following sections will outline how the author envisage flow > programming will work and also how TEP acceleration can be combined with other > accelerations. In order to allow a single TEP context object to be shared by multiple flow rules, a whole new API must be implemented and applications still have to additionally create one rte_flow rule per TEP flow_id to manage. While this probably results in shorter flow rule patterns and action lists, is it really worth it? While I understand the reasons for this approach, I'd like to push for a rte_flow-only API as much as possible, I'll provide suggestions below. > Ingress TEP decapsulation, mark and forward to queue: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The flows definition for TEP decapsulation actions should specify the full > outer packet to be matched at a minimum. The outer packet definition should > match the tunnel definition in the tep context and the tep flow id. This > example shows describes matching on the outer, marking the packet with the > VXLAN VNI and directing to a specified queue of the port. > > Source Packet > > Decapsulate Outer Hdr > / \ decap outer crc > / \ / \ > +-----+------+-----+-------+-----+------+-----+---------+-----+-----------+ > | ETH | IPv4 | UDP | VxLAN | ETH | IPv4 | TCP | PAYLOAD | CRC | OUTER CRC | > +-----+------+-----+-------+-----+------+-----+---------+-----+-----------+ > > /* Flow Attributes/Items Definitions */ > > struct rte_flow_attr attr = { .ingress = 1 }; > > struct rte_flow_item_eth eth_item = { .src = s_addr, .dst = d_addr, .type = ether_type }; > struct rte_flow_item_tep tep_item = { .tep = tep, .id = vni }; > > struct rte_flow_item pattern[] = { > { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = ð_item }, > { .type = RTE_FLOW_ITEM_TYPE_TEP, .spec = &tep_item }, > { .type = RTE_FLOW_ITEM_TYPE_END } > }; > > /* Flow Actions Definitions */ > > struct rte_flow_action_decap decap_eth = { > .type = RTE_FLOW_ITEM_TYPE_ETH, > .item = { .src = s_addr, .dst = d_addr, .type = ether_type } > }; > > struct rte_flow_action_decap decap_tep = { > .type = RTE_FLOW_ITEM_TYPE_TEP, > .spec = &tep_item > }; > > struct rte_flow_action_queue queue_action = { .index = qid }; > > struct rte_flow_action_port mark_action = { .index = vni }; > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_DECAP, .conf = &decap_eth }, > { .type = RTE_FLOW_ACTION_TYPE_DECAP, .conf = &decap_tep }, > { .type = RTE_FLOW_ACTION_TYPE_MARK, .conf = &mark_action }, > { .type = RTE_FLOW_ACTION_TYPE_QUEUE, .conf = &queue_action }, > { .type = RTE_FLOW_ACTION_TYPE_END } > }; Assuming there is no dedicated TEP API, how about something like the following pseudo-code for a VXLAN-based TEP instead: attr = ingress; pattern = eth / ipv6 / udp / vxlan vni is 42 / end; actions = vxlan_decap / mark id 92 / queue index 8 / end; flow = rte_flow_create(port_id, &attr, pattern, actions, &err); ... The VXLAN_DECAP action and its parameters (if any) remain to be defined, however VXLAN implies all layers up to and including the first VXLAN header encountered. Also, if supported/accepted by a PMD: attr = ingress; pattern = eth / any / udp / vxlan vni is 42 / end; actions = vxlan_decap / mark id 92 / queue index 8 / end; => Both outer IPv4 and IPv6 traffic taken into account at once. attr = ingress; pattern = end; actions = vxlan_decap / mark id 92 / queue index 8 / end; => All recognized VXLAN traffic regardless of VNI is acted upon. The rest simply passes through. > /** VERY IMPORTANT NOTE **/ > One of the core concepts of this proposal is that actions which modify the > packet are defined in the order which they are to be processed. So first decap > outer ethernet header, then the outer TEP headers. > I think this is not only logical from a usability point of view, it should also > simplify the logic required in PMDs to parse the desired actions. This. I've been thinking about it for a very long time but never got around submit a patch. Handling rte_flow actions in order, allowing repeated identical actions and therefore getting rid of DUP. The current approach was a bad design decision from my part, I'm convinced it must be redefined before combinations become commonplace (right now no PMD implements any action whose order matters as far as I know). > struct rte_flow *flow = > rte_flow_create(port_id, &attr, pattern, actions, &err); > > The processed packets are delivered to specifed queue with mbuf metadata > denoting marked flow id and with mbuf ol_flags PKT_RX_TEP_OFFLOAD set. > > +-----+------+-----+---------+-----+ > | ETH | IPv4 | TCP | PAYLOAD | CRC | > +-----+------+-----+---------+-----+ Yes, except for the CRC part which would be optional depending on PMD/HW capabilities. Not a big deal. > Ingress TEP decapsulation switch to port: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This is intended to represent how a TEP decapsulation could be configured > in a switching offload case, it makes an assumption that there is a logical > port representation for all ports on the hw switch in the DPDK application, > but similar functionality could be achieved by specifying something like a > VF ID of the device. > > Like the previous scenario the flows definition for TEP decapsulation actions > should specify the full outer packet to be matched at a minimum but also > define the elements of the inner match to match against including masks if > required. > > struct rte_flow_attr attr = { .ingress = 1 }; > > struct rte_flow_item pattern[] = { > { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &outer_eth_item }, > { .type = RTE_FLOW_ITEM_TYPE_TEP, .spec = &outer_tep_item, .mask = &tep_mask }, > { .type = RTE_FLOW_ITEM_TYPE_ETH, .spec = &inner_eth_item, .mask = ð_mask } > { .type = RTE_FLOW_ITEM_TYPE_IPv4, .spec = &inner_ipv4_item, .mask = &ipv4_mask }, > { .type = RTE_FLOW_ITEM_TYPE_TCP, .spec = &inner_tcp_item, .mask = &tcp_mask }, > { .type = RTE_FLOW_ITEM_TYPE_END } > }; > > /* Flow Actions Definitions */ > > struct rte_flow_action_decap decap_eth = { > .type = RTE_FLOW_ITEM_TYPE_ETH, > .item = { .src = s_addr, .dst = d_addr, .type = ether_type } > }; > > struct rte_flow_action_decap decap_tep = { > .type = RTE_FLOW_ITEM_TYPE_TEP, > .item = &outer_tep_item > }; > > struct rte_flow_action_port port_action = { .index = port_id }; > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_DECAP, .conf = &decap_eth }, > { .type = RTE_FLOW_ACTION_TYPE_DECAP, .conf = &decap_tep }, > { .type = RTE_FLOW_ACTION_TYPE_PORT, .conf = &port_action }, > { .type = RTE_FLOW_ACTION_TYPE_END } > }; > > struct rte_flow *flow = rte_flow_create(port_id, &attr, pattern, actions, &err); > > This action will forward the decapsulated packets to another port of the switch > fabric but no information will on the tunnel or the fact that the packet was > decapsulated will be passed with it, thereby enable segregation of the > infrastructure and Again a suggestion without a dedicated TEP API, matching outer and some inner as well: attr = ingress; pattern = eth / ipv6 / udp / vxlan vni is 42 / eth / ipv4 / tcp / end; actions = vxlan_decap / port index 3 / end; /* or */ actions = vxlan_decap / vf id 5 / end; The PORT action should be defined as well as the converse of the existing PORT pattern item (matching an arbitrary physical port). Specifying a PORT action would steer traffic to a nondefault physical port. The VF action is already correctly defined. > Egress TEP encapsulation: > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > Encapulsation TEP actions require the flow definitions for the source packet > and then the actions to do on that, this example shows a ipv4/tcp packet > action. > > Source Packet > > +-----+------+-----+---------+-----+ > | ETH | IPv4 | TCP | PAYLOAD | CRC | > +-----+------+-----+---------+-----+ > > struct rte_flow_attr attr = { .egress = 1 }; > > struct rte_flow_item_eth eth_item = { .src = s_addr, .dst = d_addr, .type = ether_type }; > struct rte_flow_item_ipv4 ipv4_item = { .hdr = { .src_addr = src_addr, .dst_addr = dst_addr } }; > struct rte_flow_item_udp tcp_item = { .hdr = { .src_port = src_port, .dst_port = dst_port } }; > > 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 } > }; > > /* Flow Actions Definitions */ > > struct rte_flow_action_encap encap_eth = { > .type = RTE_FLOW_ITEM_TYPE_ETH, > .item = { .src = s_addr, .dst = d_addr, .type = ether_type } > }; > > struct rte_flow_action_encap encap_tep = { > .type = RTE_FLOW_ITEM_TYPE_TEP, > .item = { .tep = tep, .id = vni } > }; > struct rte_flow_action_mark port_action = { .index = port_id }; > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_ENCAP, .conf = &encap_tep }, > { .type = RTE_FLOW_ACTION_TYPE_ENCAP, .conf = &encap_eth }, > { .type = RTE_FLOW_ACTION_TYPE_PORT, .conf = &port_action }, > { .type = RTE_FLOW_ACTION_TYPE_END } > } > struct rte_flow *flow = rte_flow_create(port_id, &attr, pattern, actions, &err); > > > encapsulating Outer Hdr > / \ outer crc > / \ / \ > +-----+------+-----+-------+-----+------+-----+---------+-----+-----------+ > | ETH | IPv4 | UDP | VxLAN | ETH | IPv4 | TCP | PAYLOAD | CRC | OUTER CRC | > +-----+------+-----+-------+-----+------+-----+---------+-----+-----------+ I see three main use cases for egress since we do not want a PMD to parse traffic in software to determine if it's candidate for TEP encapsulation: 1. Traffic generated/forwarded by an application. 2. Same as 1. assuming an application is aware hardware can match egress traffic in addition to encapsulate it. 3. Traffic fully processed internally in hardware. To handle 1., in my opinion the most common use case, PMDs should rely on an application-provided mark pattern item (the converse of the MARK action): attr = egress; pattern = mark is 42 / end; actions = vxlan_encap {many parameters} / end; To handle 2, hardware with the ability to recognize and encapsulate outgoing traffic is required (applications can rely on rte_flow_validate()): attr = egress; pattern = eth / ipv4 / tcp / end; actions = vxlan_encap {many parameters} / end; For 3, a combination of ingress and egress can be used needed on a given rule. For clarity, one should assert where traffic comes from and where it's supposed to go: attr = ingress egress; pattern = eth / ipv4 / tcp / port id 0 / end; actions = vxlan_encap {many parameters} / vf id 5 / end; The {many parameters} for VXLAN_ENCAP obviously remain to be defined, they have to either include everything needed to construct L2, L3, L4 and VXLAN headers, or separate actions for each layer specified in innermost-to-outermost order. No need for dedicated mbuf TEP flags. > Chaining multiple modification actions eg IPsec and TEP > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For example the definition for full hw acceleration for an IPsec ESP/Transport > SA encapsulated in a vxlan tunnel would look something like: > > struct rte_flow_action actions[] = { > { .type = RTE_FLOW_ACTION_TYPE_ENCAP, .conf = &encap_tep }, > { .type = RTE_FLOW_ACTION_TYPE_SECURITY, .conf = &sec_session }, > { .type = RTE_FLOW_ACTION_TYPE_ENCAP, .conf = &encap_eth }, > { .type = RTE_FLOW_ACTION_TYPE_END } > } > > 1. Source Packet > +-----+------+-----+---------+-----+ > | ETH | IPv4 | TCP | PAYLOAD | CRC | > +-----+------+-----+---------+-----+ > > 2. First Action - Tunnel Endpoint Encapsulation > > +------+-----+-------+-----+------+-----+---------+-----+ > | IPv4 | UDP | VxLAN | ETH | IPv4 | TCP | PAYLOAD | CRC | > +------+-----+-------+-----+------+-----+---------+-----+ > > 3. Second Action - IPsec ESP/Transport Security Processing > > +------+-----+-----+-------+-----+------+-----+---------+-----+-------------+ > | IPv4 | ESP | ENCRYPTED PAYLOAD | ESP TRAILER | > +------+-----+-----+-------+-----+------+-----+---------+-----+-------------+ > > 4. Third Action - Outer Ethernet Encapsulation > > +-----+------+-----+-----+-------+-----+------+-----+---------+-----+-------------+-----------+ > | ETH | IPv4 | ESP | ENCRYPTED PAYLOAD | ESP TRAILER | OUTER CRC | > +-----+------+-----+-----+-------+-----+------+-----+---------+-----+-------------+-----------+ > > This example demonstrates the importance of making the interoperation of > actions to be ordered, as in the above example, a security > action can be defined on both the inner and outer packet by simply placing > another security action at the beginning of the action list. > > It also demonstrates the rationale for not collapsing the Ethernet into > the TEP definition as when you have multiple encapsulating actions, all > could potentially be the place where the Ethernet header needs to be > defined. For completeness, here's a suggested alternative with neither dedicated TEP nor security APIs: attr = egress; pattern = mark is 42 / end; actions = vxlan_encap {many parameters} / esp_encap {many parameters} / eth_encap {many parameters} / end; Note ESP_ENCAP is not so easy given some data must be provided by the application with each transmitted packet. The current security API does not provide means to perform ESP encapsulation, it instead focuses on encryption and relies on the application to prepare headers and allocate room for the trailer. It's an unrealistic use case at the moment but shows the potential of such an API. - First question is what's your opinion regarding focusing on rte_flow instead of a TEP API? (Note for counters: one could add COUNT actions as well, what's currently missing is a way to share counters among several flow rules, which is planned as well) - Regarding dedicated encap/decap actions instead of generic ones, given all protocols have different requirements (e.g. ESP encap is on a whole different level of complexity and likely needs callbacks)? - Regarding the reliance on a MARK meta pattern item as a standard means for applications to tag egress traffic so a PMD knows what to do? - I'd like to send a deprecation notice for rte_flow regarding handling of actions (documentation and change in some PMDs to reject currently valid but seldom used flow rules accordingly) instead of a new flow attribute. Would you ack such a change for 18.05? -- Adrien Mazarguil 6WIND