From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 7A0774C99 for ; Mon, 22 Oct 2018 15:06:54 +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 3E47D800081; Mon, 22 Oct 2018 13:06:52 +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 14:06:43 +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> <222de065-60c9-1bee-0359-a3f7100515c4@solarflare.com> From: Andrew Rybchenko Message-ID: Date: Mon, 22 Oct 2018 16:06:03 +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: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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-16.957200-8.000000-10 X-TMASE-MatchedRID: vEvJ7Rh1lGgOwH4pD14DsPHkpkyUphL9Ud7Bjfo+5jQ2KlZKA26MkZnI fTb5pgJnIkaAwCx34wDCy0BNncwiaeRDjkNdVstopkIW3Gref33AWTziWGaDPFpbYq2f4jz+/Ll 2bJilUiMDfet7iIllBsrwwM67bcRVwuSjRTy/snSLzZSKyQypzCTbbsi+pqSFVI7KaIl9NhdpO9 QymnA5WbWEf7jcZ0rRiWxqXr3ONLIX/DgtOsKbJLE3FpMbg63SHUEsjxm+pgiCsBeCv8CM/Wd6E sIPt/1E5Np5Cs8+5pAbZLZQawUR5tB/8y3gYF9v84dsinZ5e1iZf5btvM85AbHjjZhCJenCp56A jxnx9+x1G0Py49F+F0TOx0C9LXzVfUZxHkB4SzueAiCmPx4NwFkMvWAuahr89yEa3tvzanYXeuQ CqIxleSAHAopEd76vFhqg7ypTb07E/zxI+7qfbYfsGfClAeTnqK0wk55enX1SnnG9Aw+D/w== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.957200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24170.003 X-MDID: 1540213613-6JWoC8d49xe3 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: Mon, 22 Oct 2018 13:06:54 -0000 On 10/17/18 11:43 AM, Ori Kam wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Wednesday, October 17, 2018 10:56 AM >> 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 >> ; Nélio Laranjeiro ; >> Yongseok Koh ; Shahaf Shuler >> >> Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add raw encapsulation action >> >> 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 mailto:orika@mellanox.com [...] >> + >> +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? >> > No it is not used for matching this is only for the encapsulation data. > The data is for PMD that needs to validate that they can decapsulate > The packet, and on some PMD there might need the specify which headers > to remove and not just number of bytes. Sorry, but I still don't understand. How should PMD or HW use it? I guess the main problem here is that it is a generic action. If it is VXLAN_DECAP, it would not be a problem and neither size nor data would be required. >> + +----------------+----------------------------------------+ >> + | ``size`` | Size of data | >> + +----------------+----------------------------------------+ >> + >> Action: ``SET_IPV4_SRC`` >> ^^^^^^^^^^^^^^^^^^^^^^^^ Andrew.