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 5EFF04C77 for ; Wed, 10 Oct 2018 08:46:01 +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 88CC3480072; Wed, 10 Oct 2018 06:45:59 +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, 10 Oct 2018 07:45:50 +0100 To: Ferruh Yigit , Ori Kam , , , Declan Doherty CC: , , , , , References: <1537995646-95260-1-git-send-email-orika@mellanox.com> <1538917054-68283-1-git-send-email-orika@mellanox.com> <9760f054-bbe9-2036-dd5d-d39edd906496@intel.com> From: Andrew Rybchenko Message-ID: <1165fc19-c68b-f13c-e2a6-eeb3f6937922@solarflare.com> Date: Wed, 10 Oct 2018 09:45:09 +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: <9760f054-bbe9-2036-dd5d-d39edd906496@intel.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-24146.003 X-TM-AS-Result: No-19.928000-8.000000-10 X-TMASE-MatchedRID: rYpa/RC+czF6DVqDv3PkvSa1MaKuob8Pt3aeg7g/usDHkH7uosEn7BKY P6tHPt700UcH7xzzjCjCy0BNncwiaeRDjkNdVstopkIW3Gref33AWTziWGaDPFpbYq2f4jz+9Ef PGYdeeeyDgmpK89aKZkD8qutfZX9J6goM8gKRlUedVNZaI2n6/7ebfccgl9iNBtV+hsEa6aMwV1 2/6ktutzEGBnjgNH92bi4j8LLyXRJwgxYekOfF4iArD+K6XhnHknjBMY7iKBLjbLJ0EUx+oGxdY BEscGcbc1zckfwSxrYCmeCknzAq476KewI9xZOBx/nZUPmsnJkWTveLitVUgfKF6mz5HSjyLKkR 5pEYe9312sJ+IIZrPYr50uL/CeFY8+RGx07+8j/AJnGRMfFxyVzNvbGcILlxB4sIhfTjqIFKslM 7VUaEwXb4Bm7FqQnLz1+7FJCqpLLIDWKFjjZHby+PrAd8gbHJCFEIkVv1y6x5UICQcvBF48Uzzd Iu4oxhNxsaF710CP/XVAJEaCob3t9faxl/I4mhngIgpj8eDcC063Wh9WVqgtQdB5NUNSsioeQzl hj3alkiEOZmeUqhz98vwSvHHaAOR+eUOCwIYowETOMwUY36JYnmNSaAqlXYqLDZK8VnGzU9QApv gR17h+jlgPJ3vq85nIoHGHaGG1oXkqpye/xkkD6Qrn3xh/cy X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--19.928000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24146.003 X-MDID: 1539153960-MtWVEiyc6ojr 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 v3 0/3] ethdev: add generic L2/L3 tunnel encapsulation actions 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, 10 Oct 2018 06:46:01 -0000 On 10/9/18 7:48 PM, Ferruh Yigit wrote: > On 10/7/2018 1:57 PM, Ori Kam wrote: >> This series implement the generic L2/L3 tunnel encapsulation actions >> and is based on rfc [1] "add generic L2/L3 tunnel encapsulation actions" >> >> 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 action >> 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 series introduce a generic encapsulation for L2 tunnel types, and >> generic encapsulation for 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. >> >> [1]https://mails.dpdk.org/archives/dev/2018-August/109944.html >> >> v3: >> * rebase on tip. >> >> v2: >> * add missing decap_l3 structure. >> * fix typo. >> >> >> Ori Kam (3): >> ethdev: add generic L2/L3 tunnel encapsulation actions >> app/testpmd: convert testpmd encap commands to new API >> ethdev: remove vxlan and nvgre encapsulation commands > Reminder of this patchset, any reviews welcome. I've added the author of previous actions in recipients. I like the idea to generalize encap/decap actions. It makes a bit harder for reader to find which encap/decap actions are supported in fact, but it changes nothing for automated usage in the code - just try it (as a generic way used in rte_flow). Arguments about a way of encap/decap headers specification (flow items vs raw) sound sensible, but I'm not sure about it. It would be simpler if the tunnel header is added appended or removed as is, but as I understand it is not true. For example, IPv4 ID will be different in incoming packets to be decapsulated and different values should be used on encapsulation. Checksums will be different (but offloaded in any case). Current way allows to specify which fields do not matter and which one must match. It allows to say that, for example, VNI match is sufficient to decapsulate. Also arguments assume that action input is accepted as is by the HW. It could be true, but could be obviously false and HW interface may require parsed input (i.e. driver must parse the input buffer and extract required fields of packet headers). So, I'd say no. It should be better motivated if we change existing approach (even advertised as experimental).