All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ori Kam <orika@mellanox.com>
Cc: xuemingl@mellanox.com, dekelp@mellanox.com, shahafs@mellanox.com,
	adrien.mazarguil@6wind.com, thomas@monjalon.net,
	yskoh@mellanox.com, ferruh.yigit@intel.com,
	arybchenko@solarflare.com, dev@dpdk.org
Subject: Re: [RFC] ethdev: add generic L2/L3 tunnel encapsulation actions
Date: Mon, 30 Jul 2018 10:28:36 -0700	[thread overview]
Message-ID: <20180730102836.00605a3e@xeon-e3> (raw)
In-Reply-To: <1532967565-13962-1-git-send-email-orika@mellanox.com>

On Mon, 30 Jul 2018 19:19:25 +0300
Ori Kam <orika@mellanox.com> wrote:

> 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,
> 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 <orika@mellanox.com>

What about binary and source compatibilities with older release?

  reply	other threads:[~2018-07-30 17:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-30 16:19 [RFC] ethdev: add generic L2/L3 tunnel encapsulation actions Ori Kam
2018-07-30 17:28 ` Stephen Hemminger [this message]
2018-07-30 18:02   ` Ori Kam
2018-08-22  5:57   ` Ori Kam
2018-08-23 12:12 ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180730102836.00605a3e@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=adrien.mazarguil@6wind.com \
    --cc=arybchenko@solarflare.com \
    --cc=dekelp@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=xuemingl@mellanox.com \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.