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 4CDDD4C95 for ; Mon, 22 Oct 2018 15:28:49 +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 7C7FCB80070; Mon, 22 Oct 2018 13:28:46 +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:28:37 +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: <4c172bc9-2213-089e-0061-34028f888613@solarflare.com> Date: Mon, 22 Oct 2018 16:27:58 +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-22.065200-8.000000-10 X-TMASE-MatchedRID: PL66URbwWA8OwH4pD14DsPHkpkyUphL9Ud7Bjfo+5jQ2KlZKA26MkZnI fTb5pgJniUtmJJmYY1EhcnM8qCdEavtAPEfr8cPblUgQqGVMqmwZj1j4BNp7XGCD5SM8YvVFoPW ckIQF9ouwxDrU1KVUj7EYeoHQ4w3lgFWhWut0cL24jAucHcCqnb8+q17GFLKR7a71bENFnTPU00 xRT8R7/qWLoyPvPL17VOGWj1p6KT5BPwZMJT4qdlFgymyXggMtN/BTU5ZfZRL9nZJIPtHyFPRm0 kmqtH+DTAfey7Yae3HWaTF7Z7u1pW00sCPwNg7wDB+ErBr0bANimi8LvNfmr9vpj5+dNlQv2Tot Q/h2COBwR3kDso7qDxoml0Wru3vSk4P+vqTbTVHr/EBmiNuXtwRryDXHx6oXyL0CMroLynWd5kC SHR2EYsY9rykQMQjShm1M+l73i84oZZgCxeSxyPQAclqqmRB8IM86Aeo6sYIRtWN95myZBaPFjJ EFr+oloTCA5Efyn8DyABN92SNtPElXctromFFi+gtHj7OwNO0CpgETeT0ynA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--22.065200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24170.003 X-MDID: 1540214928-SnrbGGyLX7sl 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:28:49 -0000 On 10/22/18 4:19 PM, Ori Kam wrote: >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Monday, October 22, 2018 4:06 PM >> 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 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. >> > The data is buffer of the encap/decap headers, so the PMD can parse the this data > and check the validity and if the HW supports it. > Some NICs will not use this others can check if the tunnel request is valid. > For example let's assume that some tunnel encapsulation is supported on some FW version > and not supported in other version so the PMD can check the encapsulation data to see > what is the requested tunnel type and the FW capabilities to return success or fail. OK, I see. Could you improve the action description to make it clear. Right now the description says nothing about it.