All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Benc <jbenc@redhat.com>
To: netdev@vger.kernel.org
Subject: [PATCH net-next 0/7] vxlan: clean up rx path, consolidating extension handling
Date: Tue, 16 Feb 2016 21:58:56 +0100	[thread overview]
Message-ID: <cover.1455656217.git.jbenc@redhat.com> (raw)

The rx path of VXLAN turned over time into kind of spaghetti code. The rx
processing is split between vxlan_udp_encap_recv and vxlan_rcv but in an
artificial way: vxlan_rcv is just called at the end of vxlan_udp_encap_recv,
continuing the rx processing where vxlan_udp_encap_recv left it. There's no
clear border between those two functions.

It makes sense to combine those functions into one; this will be actually
needed for VXLAN-GPE where we'll need to skip part of the processing which
is hard to do with the current code.

However, both functions are too long already. This patchset is shortening
them, consolidating extension handling that is spread all around together
and moving it to separate functions. (Later patchsets will do more
consolidation in other parts of the functions with the final goal of merging
vxlan_udp_encap_recv and vxlan_rcv.)

In process of consolidation of the extension handling, I needed to deal with
vni field in a generic way, as its lower 8 bits mean different things for
different extensions. While cleaning up the code to strictly distinguish
between "vni" and "vni field" (which contains vni plus an additional byte),
I also converted the code not to convert endianess back and forth.

The full picture can be seen at:
https://github.com/jbenc/linux-vxlan/commits/master

Jiri Benc (7):
  vxlan: introduce vxlan_hdr
  vxlan: keep flags and vni in network byte order
  vxlan: simplify vxlan_remcsum
  vxlan: move GBP header parsing to a separate function
  vxlan: clean up extension handling on rx
  vxlan: clean up rx error path
  vxlan: treat vni in metadata based tunnels consistently

 drivers/net/vxlan.c | 228 +++++++++++++++++++++++++---------------------------
 include/net/vxlan.h |  75 ++++++++++++++---
 2 files changed, 173 insertions(+), 130 deletions(-)

-- 
1.8.3.1

             reply	other threads:[~2016-02-16 20:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-16 20:58 Jiri Benc [this message]
2016-02-16 20:58 ` [PATCH net-next 1/7] vxlan: introduce vxlan_hdr Jiri Benc
2016-02-16 20:58 ` [PATCH net-next 2/7] vxlan: keep flags and vni in network byte order Jiri Benc
2016-02-16 20:58 ` [PATCH net-next 3/7] vxlan: simplify vxlan_remcsum Jiri Benc
2016-02-16 20:59 ` [PATCH net-next 4/7] vxlan: move GBP header parsing to a separate function Jiri Benc
2016-02-16 20:59 ` [PATCH net-next 5/7] vxlan: clean up extension handling on rx Jiri Benc
2016-02-16 20:59 ` [PATCH net-next 6/7] vxlan: clean up rx error path Jiri Benc
2016-02-16 20:59 ` [PATCH net-next 7/7] vxlan: treat vni in metadata based tunnels consistently Jiri Benc

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=cover.1455656217.git.jbenc@redhat.com \
    --to=jbenc@redhat.com \
    --cc=netdev@vger.kernel.org \
    /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.