Hi all,

Just looking for more comments if any 😊

Best,

Ori

-----Original Message-----
From: Ori Kam
Sent: Monday, July 30, 2018 9:03 PM
To: 'Stephen Hemminger' <stephen@networkplumber.org>
Cc: Xueming(Steven) Li <redacted>; Dekel Peled
[off-list ref]; Shahaf Shuler [off-list ref]; Adrien
Mazarguil [off-list ref]; Thomas Monjalon
[off-list ref]; Yongseok Koh [off-list ref];
ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org
Subject: RE: [dpdk-dev] [RFC] ethdev: add generic L2/L3 tunnel
encapsulation actions

quoted

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Monday, July 30, 2018 8:29 PM
To: Ori Kam <redacted>
Cc: Xueming(Steven) Li <redacted>; Dekel Peled
[off-list ref]; Shahaf Shuler [off-list ref];

Adrien

quoted

Mazarguil [off-list ref]; Thomas Monjalon
[off-list ref]; Yongseok Koh [off-list ref];
ferruh.yigit@intel.com; arybchenko@solarflare.com; dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] ethdev: add generic L2/L3 tunnel
encapsulation actions

On Mon, 30 Jul 2018 19:19:25 +0300
Ori Kam [off-list ref] wrote:

quoted

Currenlty the encap/decap actions only support encapsulation
of VXLAN and NVGRE L2 packets.
There is a need to add more L2 tunnels and also L3 tunnels.

One issue with the current approch is the duplication of code.
For example the code for handling NVGRE and VXLAN are exactly the

same,

quoted

and each new tunnel will have the same exact structure.

Last issue with the current approach is the use of rte_items.
The most significant issue with that is that the PMD needs to convert
the items and this hurts the insertion rate. Other issue is that
the rte_item has 3 members while we only need the spec (last and mask
are useless). I know that the extra member have only small memory
impact but considering that we can have millions of rules, this became
more important consideration, and it is bad practice to add a variable
that is never used.

My suggestion is to create 2 commands, one for encapsulation of L2
packets and one for encapsulation of L3 tunnels.
The parameters for those functions will be a uint8_t buffer with
a length parameter.

The current approach is not implemented yet in drivers yet, and
is marked as experimental, so it should be removed.

Any comments will be hugely appreciated.

Signed-off-by: Ori Kam <redacted>

What about binary and source compatibilities with older release?

I'm not sure what you mean, currently this feature is not implemented
In any PMD (as far as I can see) so no one uses it, and it is marked as
experimental. In any case if this is an issue we can keep the old one and just
add the new one.

Best,
Ori