From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 5E9416833 for ; Wed, 17 Oct 2018 09:57:17 +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-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id E6C4A9C00A7; Wed, 17 Oct 2018 07:57:15 +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; Wed, 17 Oct 2018 08:57:06 +0100 To: Ori Kam , "wenzhuo.lu@intel.com" , "jingjing.wu@intel.com" , "bernard.iremonger@intel.com" , "ferruh.yigit@intel.com" , "stephen@networkplumber.org" , Adrien Mazarguil CC: "dev@dpdk.org" , Dekel Peled , "Thomas Monjalon" , =?UTF-8?Q?N=c3=a9lio_Laranjeiro?= , Yongseok Koh , "Shahaf Shuler" References: <1538917054-68283-1-git-send-email-orika@mellanox.com> <1539726023-14402-1-git-send-email-orika@mellanox.com> <1539726023-14402-2-git-send-email-orika@mellanox.com> From: Andrew Rybchenko Message-ID: <222de065-60c9-1bee-0359-a3f7100515c4@solarflare.com> Date: Wed, 17 Oct 2018 10:56:26 +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: <1539726023-14402-2-git-send-email-orika@mellanox.com> 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-24160.003 X-TM-AS-Result: No-19.379000-8.000000-10 X-TMASE-MatchedRID: gzVbiXtWD9sOwH4pD14DsPHkpkyUphL9f6/Md8Lb2l8cVJCT3tVgaupi uk7UuTK1jnjhzrwNMkio9mVPG4tN5zmSGDnCxsH2nhHKNOYbLL4hHWssEmb8zmecrqZc3vabDwu oklp2aaX/J8PbdeOOgSMdorAXp9XrQOfw0USEkBxc/msUC5wFQUyQ5fRSh265WabPstVV86mxEI pMo/Df4CCIerDoEZQAFvWZfUUZ7wtSZHVmVfdoUkKcYi5Qw/RV2aYdnwn7qHd/y29NnT7OA8uxW 1Xm4Begaum91FuYKHZB92DaXikay4he7fZGGor+MJoQm3jo+mlKDzk/xkzLhraH9+2kCKjsgXZ9 BcjTfaT3B+HtdwJeNCTDX0HcFwsWNuVzoZ6LieUiPTMUjkOgkl4KsHfYo5LQowtRP8whCK8K8Tr y7xT2TxHh35S+GXSq/VWmtOMs6xHDeKeENmQ9GWY0Io4Kxb86x22bBvE+WY47LF3pX3rdVLjxa5 EVBV1q4vM1YF6AJbZFi+KwZZttL7ew1twePJJBOwBXM346/+yahgpaatYjCl7tg5LJGy5t3MfuH wc1vw+SA+74HxgPuQ3D+OuhYfpZ X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--19.379000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24160.003 X-MDID: 1539763037-bK2QslPvNceS Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 07:57:17 -0000 On 10/17/18 12:41 AM, 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 negetive 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 [...] > +Action: ``RAW_DECAP`` > +^^^^^^^^^^^^^^^^^^^^^^^ > + > +Remove outer header whose template is provided in it's data buffer, Typo: 'it's' -> its > +as defined in hte ``rte_flow_action_raw_decap`` Typo above 'hte' -> 'the'. > + > +This action modifies the payload of matched flows. The data supplied must > +be a valid header, either holding layer 2 data in case of removing layer 2 > +before incapsulation of layer 3 tunnel (for example MPLSoGRE) or complete > +tunnel definition starting from layer 2 and moving to the tunel item itself. > +When applied to the original packet the resulting packet must be a > +valid packet. > + > +.. _table_rte_flow_action_raw_decap: > + > +.. table:: RAW_DECAP > + > + +----------------+----------------------------------------+ > + | Field | Value | > + +================+========================================+ > + | ``data`` | Decapsulation data | Sorry, I've missed the point why it is here. Is it used for matching? Why is the size insufficient? > + +----------------+----------------------------------------+ > + | ``size`` | Size of data | > + +----------------+----------------------------------------+ > + > Action: ``SET_IPV4_SRC`` > ^^^^^^^^^^^^^^^^^^^^^^^^ > > diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c > index bc9e719..1e5cd73 100644 > --- a/lib/librte_ethdev/rte_flow.c > +++ b/lib/librte_ethdev/rte_flow.c > @@ -123,6 +123,8 @@ struct rte_flow_desc_data { > MK_FLOW_ACTION(VXLAN_DECAP, 0), > MK_FLOW_ACTION(NVGRE_ENCAP, sizeof(struct rte_flow_action_vxlan_encap)), > MK_FLOW_ACTION(NVGRE_DECAP, 0), > + MK_FLOW_ACTION(RAW_ENCAP, sizeof(struct rte_flow_action_raw_encap)), > + MK_FLOW_ACTION(RAW_DECAP, sizeof(struct rte_flow_action_raw_decap)), > MK_FLOW_ACTION(SET_IPV4_SRC, > sizeof(struct rte_flow_action_set_ipv4)), > MK_FLOW_ACTION(SET_IPV4_DST, > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index 68bbf57..3ae9de3 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -1508,6 +1508,20 @@ enum rte_flow_action_type { > RTE_FLOW_ACTION_TYPE_NVGRE_DECAP, > > /** > + * Adds outer header whose template is provided in it's data buffer Adds -> Add, it's -> its > + * > + * See struct rte_flow_action_raw_encap. > + */ > + RTE_FLOW_ACTION_TYPE_RAW_ENCAP, > + > + /** > + * Remove outer header whose tempalte is provided in it's data buffer. it's -> its > + * > + * See struct rte_flow_action_raw_decap > + */ > + RTE_FLOW_ACTION_TYPE_RAW_DECAP, > + > + /** > * Modify IPv4 source address in the outermost IPv4 header. > * > * If flow pattern does not define a valid RTE_FLOW_ITEM_TYPE_IPV4, > @@ -1946,6 +1960,51 @@ struct rte_flow_action_nvgre_encap { > * @warning > * @b EXPERIMENTAL: this structure may change without prior notice > * > + * RTE_FLOW_ACTION_TYPE_RAW_ENCAP > + * > + * Raw tunnel end-point encapsulation data definition. > + * > + * The data holds the headers definitions to be applied on the packet. > + * The data must start with ETH header up to the tunnel item header itself. > + * When used right after RAW_DECAP (for decapsulating L3 tunnel type for > + * example MPLSoGRE) the data will just hold layer 2 header. > + * > + * The preserve parameter holds which bits in the packet the PMD is not allowd allowd -> allowed