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 7A0774C99
 for <dev@dpdk.org>; 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 <orika@mellanox.com>, "wenzhuo.lu@intel.com"
 <wenzhuo.lu@intel.com>, "jingjing.wu@intel.com" <jingjing.wu@intel.com>,
 "bernard.iremonger@intel.com" <bernard.iremonger@intel.com>,
 "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
 "stephen@networkplumber.org" <stephen@networkplumber.org>, Adrien Mazarguil
 <adrien.mazarguil@6wind.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, Dekel Peled <dekelp@mellanox.com>, "Thomas
 Monjalon" <thomas@monjalon.net>, =?UTF-8?Q?N=c3=a9lio_Laranjeiro?=
 <nelio.laranjeiro@6wind.com>, Yongseok Koh <yskoh@mellanox.com>, "Shahaf
 Shuler" <shahafs@mellanox.com>
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>
 <AM4PR05MB3425EC1658D0247BFB5B6167DBFF0@AM4PR05MB3425.eurprd05.prod.outlook.com>
From: Andrew Rybchenko <arybchenko@solarflare.com>
Message-ID: <d8db9e13-c822-6493-9a73-44caf4a8bd9d@solarflare.com>
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: <AM4PR05MB3425EC1658D0247BFB5B6167DBFF0@AM4PR05MB3425.eurprd05.prod.outlook.com>
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 <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 13:06:54 -0000

On 10/17/18 11:43 AM, Ori Kam wrote:
>> -----Original Message-----
>> From: Andrew Rybchenko <arybchenko@solarflare.com>
>> Sent: Wednesday, October 17, 2018 10:56 AM
>> To: Ori Kam <orika@mellanox.com>; wenzhuo.lu@intel.com;
>> jingjing.wu@intel.com; bernard.iremonger@intel.com; ferruh.yigit@intel.com;
>> stephen@networkplumber.org; Adrien Mazarguil
>> <adrien.mazarguil@6wind.com>
>> Cc: dev@dpdk.org; Dekel Peled <dekelp@mellanox.com>; Thomas Monjalon
>> <thomas@monjalon.net>; Nélio Laranjeiro <nelio.laranjeiro@6wind.com>;
>> Yongseok Koh <yskoh@mellanox.com>; Shahaf Shuler
>> <shahafs@mellanox.com>
>> 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.