Merge branch 'vxlan-gpe'
authorDavid S. Miller <davem@davemloft.net>
Wed, 6 Apr 2016 20:50:33 +0000 (16:50 -0400)
committerDavid S. Miller <davem@davemloft.net>
Wed, 6 Apr 2016 20:50:33 +0000 (16:50 -0400)
commit6f5556356a1ed288fd24f0521a9c606632ad9e1f
tree1e18cdabf1c9d9ef17e26c6480e629465447f77f
parent8a21ec4e0abb99884ef2da3e4f950025f3bf7fd3
parente1e5314de08ba6003b358125eafc9ad9e75a950c
Merge branch 'vxlan-gpe'

Jiri Benc says:

====================
vxlan: implement Generic Protocol Extension (GPE)

v3: just rebased on top of the current net-next, no changes

This patchset implements VXLAN-GPE. It follows the same model as the tun/tap
driver: depending on the chosen mode, the vxlan interface is created either
as ARPHRD_ETHER (non-GPE) or ARPHRD_NONE (GPE).

Note that the internal fdb control plane cannot be used together with
VXLAN-GPE and attempt to configure it will be rejected by the driver. In
fact, COLLECT_METADATA is required to be set for now. This can be relaxed in
the future by adding support for static PtP configuration; it will be
backward compatible and won't affect existing users.

The previous version of the patchset supported two GPE modes, L2 and L3. The
L2 mode (now called "ether mode" in the code) was removed from this version.
It can be easily added later if there's demand. The L3 mode is now called
"raw mode" and supports also encapsulated Ethernet headers (via ETH_P_TEB).

The only limitation of not having "ether mode" for GPE is for ip route based
encapsulation: with such setup, only IP packets can be encapsulated. Meaning
no Ethernet encapsulation. It seems there's not much use for this, though.
If it turns out to be useful, we'll add it.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>