Skip to content

vxlan: clean up rx path, consolidating extension handling

Jiri Benc netdev 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest7 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/7vxlan: introduce vxlan_hdrdrivers/net/vxlan.c include/net/vxlan.h+12 -100 replies
2/7vxlan: keep flags and vni in network byte orderdrivers/net/vxlan.c include/net/vxlan.h+116 -690 replies
3/7vxlan: simplify vxlan_remcsumdrivers/net/vxlan.c+8 -140 replies
4/7vxlan: move GBP header parsing to a separate functiondrivers/net/vxlan.c+19 -140 replies
5/7vxlan: clean up extension handling on rxdrivers/net/vxlan.c+32 -300 replies
6/7vxlan: clean up rx error pathdrivers/net/vxlan.c+14 -210 replies
7/7vxlan: treat vni in metadata based tunnels consistentlydrivers/net/vxlan.c+4 -40 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH net-next 0/7] vxlan: clean up rx path, consolidating extension handling

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(-)
Signature · 1 line
1.8.3.1