From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 9266D5F1A for <dev@dpdk.org>; Mon, 22 Oct 2018 16:16:41 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 50A704C0070; Mon, 22 Oct 2018 14:16:38 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 15:16:28 +0100 To: Ori Kam <orika@mellanox.com>, <wenzhuo.lu@intel.com>, <jingjing.wu@intel.com>, <bernard.iremonger@intel.com>, <arybchenko@solarflare.com>, <ferruh.yigit@intel.com>, <stephen@networkplumber.org>, <adrien.mazarguil@6wind.com> CC: <dev@dpdk.org>, <dekelp@mellanox.com>, <thomas@monjalon.net>, <nelio.laranjeiro@6wind.com>, <yskoh@mellanox.com>, <shahafs@mellanox.com> References: <1539726023-14402-1-git-send-email-orika@mellanox.com> <1539796072-111646-1-git-send-email-orika@mellanox.com> <1539796072-111646-2-git-send-email-orika@mellanox.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <b116c81a-abf6-af6f-c669-055ba9016e55@solarflare.com> Date: Mon, 22 Oct 2018 17:15:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1539796072-111646-2-git-send-email-orika@mellanox.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24170.003 X-TM-AS-Result: No-7.711900-8.000000-10 X-TMASE-MatchedRID: zGP2F0O7j/sOwH4pD14DsPHkpkyUphL9f6/Md8Lb2l8cVJCT3tVgaupi uk7UuTK1ga94sNw62T6bOrGeb7+ySK+E45fdyyZX46qridCOdGA4gG1vqBBN+ES/boWSGMtdJz/ Fli73wMilXUU7yxjrICQ28VgeTQO4hrD3pNcSx1YbmaDSnOqZfrBH/AqZyGLZ31GU/N5W5BAOlu t2Fx3n+RF9goDxV3zokZOl7WKIImrvXOvQVlExsG4djWaei+WE+gD2vYtOFhgqtq5d3cxkNblvU lETg/ppNXIP9wgGxyl1tvYK5b66Lilo9slFSsyUyXiAtjUFXD/EHgf1tn3c447WxpzweuayL5dQ Z597V65Ffbjfq7oio7Du8kSu3mDoBsRAh8WmTAcG2WAWHb2qekrMHC7kmmSWWgpFdCbsUfc= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.711900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24170.003 X-MDID: 1540217799-eXrKgzG2NK9q Subject: Re: [dpdk-dev] [PATCH v5 1/3] ethdev: add raw encapsulation action 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://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 22 Oct 2018 14:16:42 -0000 On 10/17/18 8:07 PM, Ori Kam wrote: > Currenlty the encap/decap actions only support encapsulation > of VXLAN and NVGRE L2 packets (L2 encapsulation is where > the inner packet has a valid Ethernet header, while L3 encapsulation > is where the inner packet doesn't have the Ethernet header). > In addtion the parameter to to the encap action is a list of rte items, > this results in 2 extra translation, between the application to the > actioni and from the action to the NIC. This results in negative impact > on the insertion performance. > > Looking forward there are going to be a need to support many more tunnel > encapsulations. For example MPLSoGRE, MPLSoUDP. > Adding the new encapsulation will result in duplication of code. > For example the code for handling NVGRE and VXLAN are exactly the same, > and each new tunnel will have the same exact structure. > > This patch introduce a raw encapsulation that can support L2 tunnel types > and L3 tunnel types. In addtion the new > encapsulations commands are using raw buffer inorder to save the > converstion time, both for the application and the PMD. > > In order to encapsulate L3 tunnel type there is a need to use both > actions in the same rule: The decap to remove the L2 of the original > packet, and then encap command to encapsulate the packet with the > tunnel. > For decap L3 there is also a need to use both commands in the same flow > first the decap command to remove the outer tunnel header and then encap > to add the L2 header. > > Signed-off-by: Ori Kam <orika@mellanox.com> One nit below Acked-by: Andrew Rybchenko <arybchenko@solarflare.com> [...] > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index a5ec441..5212b18 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -2076,6 +2076,57 @@ RTE_FLOW_ERROR_TYPE_ACTION error should be returned. > > This action modifies the payload of matched flows. > > +Action: ``RAW_ENCAP`` > +^^^^^^^^^^^^^^^^^^^^^ > + > +Adds outer header whose template is provided in it's data buffer, it's -> its