1. 17 Jun, 2016 3 commits
  2. 03 May, 2016 1 commit
  3. 21 Apr, 2016 1 commit
    • Hannes Frederic Sowa's avatar
      vxlan: break dependency with netdev drivers · b7aade15
      Hannes Frederic Sowa authored
      Currently all drivers depend and autoload the vxlan module because how
      vxlan_get_rx_port is linked into them. Remove this dependency:
      
      By using a new event type in the netdevice notifier call chain we proxy
      the request from the drivers to flush and resetup the vxlan ports not
      directly via function call but by the already existing netdevice
      notifier call chain.
      
      I added a separate new event type, NETDEV_OFFLOAD_PUSH_VXLAN, to do so.
      We don't need to save those ids, as the event type field is an unsigned
      long and using specialized event types for this purpose seemed to be a
      more elegant way. This also comes in beneficial if in future we want to
      add offloading knobs for vxlan.
      
      Cc: Jesse Gross <jesse@kernel.org>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7aade15
  4. 16 Apr, 2016 1 commit
    • Hannes Frederic Sowa's avatar
      vxlan: synchronously and race-free destruction of vxlan sockets · 0412bd93
      Hannes Frederic Sowa authored
      Due to the fact that the udp socket is destructed asynchronously in a
      work queue, we have some nondeterministic behavior during shutdown of
      vxlan tunnels and creating new ones. Fix this by keeping the destruction
      process synchronous in regards to the user space process so IFF_UP can
      be reliably set.
      
      udp_tunnel_sock_release destroys vs->sock->sk if reference counter
      indicates so. We expect to have the same lifetime of vxlan_sock and
      vxlan_sock->sock->sk even in fast paths with only rcu locks held. So
      only destruct the whole socket after we can be sure it cannot be found
      by searching vxlan_net->sock_list.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jiri Benc <jbenc@redhat.com>
      Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0412bd93
  5. 07 Apr, 2016 1 commit
  6. 06 Apr, 2016 1 commit
    • Jiri Benc's avatar
      vxlan: implement GPE · e1e5314d
      Jiri Benc authored
      Implement VXLAN-GPE. Only COLLECT_METADATA is supported for now (it is
      possible to support static configuration, too, if there is demand for it).
      
      The GPE header parsing has to be moved before iptunnel_pull_header, as we
      need to know the protocol.
      
      v2: Removed what was called "L2 mode" in v1 of the patchset. Only "L3 mode"
          (now called "raw mode") is added by this patch. This mode does not allow
          Ethernet header to be encapsulated in VXLAN-GPE when using ip route to
          specify the encapsulation, IP header is encapsulated instead. The patch
          does support Ethernet to be encapsulated, though, using ETH_P_TEB in
          skb->protocol. This will be utilized by other COLLECT_METADATA users
          (openvswitch in particular).
      
          If there is ever demand for Ethernet encapsulation with VXLAN-GPE using
          ip route, it's easy to add a new flag switching the interface to
          "Ethernet mode" (called "L2 mode" in v1 of this patchset). For now,
          leave this out, it seems we don't need it.
      
          Disallowed more flag combinations, especially RCO with GPE.
          Added comment explaining that GBP and GPE cannot be set together.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1e5314d
  7. 21 Mar, 2016 1 commit
  8. 11 Mar, 2016 1 commit
  9. 21 Feb, 2016 1 commit
  10. 18 Feb, 2016 1 commit
  11. 17 Feb, 2016 2 commits
  12. 16 Feb, 2016 1 commit
  13. 07 Feb, 2016 3 commits
  14. 15 Dec, 2015 1 commit
    • Tom Herbert's avatar
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert authored
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a188222b
  15. 05 Dec, 2015 1 commit
  16. 26 Sep, 2015 1 commit
  17. 25 Aug, 2015 1 commit
  18. 23 Aug, 2015 1 commit
  19. 20 Aug, 2015 1 commit
  20. 07 Aug, 2015 1 commit
  21. 21 Jul, 2015 3 commits
    • Thomas Graf's avatar
      openvswitch: Use regular VXLAN net_device device · 614732ea
      Thomas Graf authored
      This gets rid of all OVS specific VXLAN code in the receive and
      transmit path by using a VXLAN net_device to represent the vport.
      Only a small shim layer remains which takes care of handling the
      VXLAN specific OVS Netlink configuration.
      
      Unexports vxlan_sock_add(), vxlan_sock_release(), vxlan_xmit_skb()
      since they are no longer needed.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      614732ea
    • Thomas Graf's avatar
      vxlan: Factor out device configuration · 0dfbdf41
      Thomas Graf authored
      This factors out the device configuration out of the RTNL newlink
      API which allows for in-kernel creation of VXLAN net_devices.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0dfbdf41
    • Thomas Graf's avatar
      vxlan: Flow based tunneling · ee122c79
      Thomas Graf authored
      Allows putting a VXLAN device into a new flow-based mode in which
      skbs with a ip_tunnel_info dst metadata attached will be encapsulated
      according to the instructions stored in there with the VXLAN device
      defaults taken into consideration.
      
      Similar on the receive side, if the VXLAN_F_COLLECT_METADATA flag is
      set, the packet processing will populate a ip_tunnel_info struct for
      each packet received and attach it to the skb using the new metadata
      dst.  The metadata structure will contain the outer header and tunnel
      header fields which have been stripped off. Layers further up in the
      stack such as routing, tc or netfitler can later match on these fields
      and perform forwarding. It is the responsibility of upper layers to
      ensure that the flag is set if the metadata is needed. The flag limits
      the additional cost of metadata collecting based on demand.
      
      This prepares the VXLAN device to be steered by the routing and other
      subsystems which allows to support encapsulation for a large number
      of tunnel endpoints and tunnel ids through a single net_device which
      improves the scalability.
      
      It also allows for OVS to leverage this mode which in turn allows for
      the removal of the OVS specific VXLAN code.
      
      Because the skb is currently scrubed in vxlan_rcv(), the attachment of
      the new dst metadata is postponed until after scrubing which requires
      the temporary addition of a new member to vxlan_metadata. This member
      is removed again in a later commit after the indirect VXLAN receive API
      has been removed.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee122c79
  22. 07 Apr, 2015 1 commit
  23. 13 Mar, 2015 1 commit
    • Alexey Kodanev's avatar
      vxlan: fix wrong usage of VXLAN_VID_MASK · 40fb70f3
      Alexey Kodanev authored
      commit dfd8645e wrongly assumes that VXLAN_VDI_MASK includes
      eight lower order reserved bits of VNI field that are using for remote
      checksum offload.
      
      Right now, when VNI number greater then 0xffff, vxlan_udp_encap_recv()
      will always return with 'bad_flag' error, reducing the usable vni range
      from 0..16777215 to 0..65535. Also, it doesn't really check whether RCO
      bits processed or not.
      
      Fix it by adding new VNI mask which has all 32 bits of VNI field:
      24 bits for id and 8 bits for other usage.
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40fb70f3
  24. 11 Mar, 2015 1 commit
  25. 11 Feb, 2015 1 commit
  26. 25 Jan, 2015 1 commit
  27. 14 Jan, 2015 3 commits
    • Thomas Graf's avatar
      vxlan: Only bind to sockets with compatible flags enabled · ac5132d1
      Thomas Graf authored
      A VXLAN net_device looking for an appropriate socket may only consider
      a socket which has a matching set of flags/extensions enabled. If
      incompatible flags are enabled, return a conflict to have the caller
      create a distinct socket with distinct port.
      
      The OVS VXLAN port is kept unaware of extensions at this point.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac5132d1
    • Thomas Graf's avatar
      vxlan: Group Policy extension · 3511494c
      Thomas Graf authored
      Implements supports for the Group Policy VXLAN extension [0] to provide
      a lightweight and simple security label mechanism across network peers
      based on VXLAN. The security context and associated metadata is mapped
      to/from skb->mark. This allows further mapping to a SELinux context
      using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
      tc, etc.
      
      The group membership is defined by the lower 16 bits of skb->mark, the
      upper 16 bits are used for flags.
      
      SELinux allows to manage label to secure local resources. However,
      distributed applications require ACLs to implemented across hosts. This
      is typically achieved by matching on L2-L4 fields to identify the
      original sending host and process on the receiver. On top of that,
      netlabel and specifically CIPSO [1] allow to map security contexts to
      universal labels.  However, netlabel and CIPSO are relatively complex.
      This patch provides a lightweight alternative for overlay network
      environments with a trusted underlay. No additional control protocol
      is required.
      
                 Host 1:                       Host 2:
      
            Group A        Group B        Group B     Group A
            +-----+   +-------------+    +-------+   +-----+
            | lxc |   | SELinux CTX |    | httpd |   | VM  |
            +--+--+   +--+----------+    +---+---+   +--+--+
      	  \---+---/                     \----+---/
      	      |                              |
      	  +---+---+                      +---+---+
      	  | vxlan |                      | vxlan |
      	  +---+---+                      +---+---+
      	      +------------------------------+
      
      Backwards compatibility:
      A VXLAN-GBP socket can receive standard VXLAN frames and will assign
      the default group 0x0000 to such frames. A Linux VXLAN socket will
      drop VXLAN-GBP  frames. The extension is therefore disabled by default
      and needs to be specifically enabled:
      
         ip link add [...] type vxlan [...] gbp
      
      In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
      must run on a separate port number.
      
      Examples:
       iptables:
        host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
        host2# iptables -I INPUT -m mark --mark 0x200 -j DROP
      
       OVS:
        # ovs-ofctl add-flow br0 'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
        # ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'
      
      [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
      [1] http://lwn.net/Articles/204905/Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3511494c
    • Tom Herbert's avatar
      vxlan: Remote checksum offload · dfd8645e
      Tom Herbert authored
      Add support for remote checksum offload in VXLAN. This uses a
      reserved bit to indicate that RCO is being done, and uses the low order
      reserved eight bits of the VNI to hold the start and offset values in a
      compressed manner.
      
      Start is encoded in the low order seven bits of VNI. This is start >> 1
      so that the checksum start offset is 0-254 using even values only.
      Checksum offset (transport checksum field) is indicated in the high
      order bit in the low order byte of the VNI. If the bit is set, the
      checksum field is for UDP (so offset = start + 6), else checksum
      field is for TCP (so offset = start + 16). Only TCP and UDP are
      supported in this implementation.
      
      Remote checksum offload for VXLAN is described in:
      
      https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
      
      Tested by running 200 TCP_STREAM connections with VXLAN (over IPv4).
      
      With UDP checksums and Remote Checksum Offload
        IPv4
            Client
              11.84% CPU utilization
            Server
              12.96% CPU utilization
            9197 Mbps
        IPv6
            Client
              12.46% CPU utilization
            Server
              14.48% CPU utilization
            8963 Mbps
      
      With UDP checksums, no remote checksum offload
        IPv4
            Client
              15.67% CPU utilization
            Server
              14.83% CPU utilization
            9094 Mbps
        IPv6
            Client
              16.21% CPU utilization
            Server
              14.32% CPU utilization
            9058 Mbps
      
      No UDP checksums
        IPv4
            Client
              15.03% CPU utilization
            Server
              23.09% CPU utilization
            9089 Mbps
        IPv6
            Client
              16.18% CPU utilization
            Server
              26.57% CPU utilization
             8954 Mbps
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfd8645e
  28. 12 Jan, 2015 1 commit
    • Tom Herbert's avatar
      vxlan: Improve support for header flags · 3bf39475
      Tom Herbert authored
      This patch cleans up the header flags of VXLAN in anticipation of
      defining some new ones:
      
      - Move header related definitions from vxlan.c to vxlan.h
      - Change VXLAN_FLAGS to be VXLAN_HF_VNI (only currently defined flag)
      - Move check for unknown flags to after we find vxlan_sock, this
        assumes that some flags may be processed based on tunnel
        configuration
      - Add a comment about why the stack treating unknown set flags as an
        error instead of ignoring them
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bf39475
  29. 26 Dec, 2014 1 commit
    • Jesse Gross's avatar
      net: Generalize ndo_gso_check to ndo_features_check · 5f35227e
      Jesse Gross authored
      GSO isn't the only offload feature with restrictions that
      potentially can't be expressed with the current features mechanism.
      Checksum is another although it's a general issue that could in
      theory apply to anything. Even if it may be possible to
      implement these restrictions in other ways, it can result in
      duplicate code or inefficient per-packet behavior.
      
      This generalizes ndo_gso_check so that drivers can remove any
      features that don't make sense for a given packet, similar to
      netif_skb_features(). It also converts existing driver
      restrictions to the new format, completing the work that was
      done to support tunnel protocols since the issues apply to
      checksums as well.
      
      By actually removing features from the set that are used to do
      offloading, it solves another problem with the existing
      interface. In these cases, GSO would run with the original set
      of features and not do anything because it appears that
      segmentation is not required.
      
      CC: Tom Herbert <therbert@google.com>
      CC: Joe Stringer <joestringer@nicira.com>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      Acked-by: default avatarTom Herbert <therbert@google.com>
      Fixes: 04ffcb25 ("net: Add ndo_gso_check")
      Tested-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f35227e
  30. 18 Nov, 2014 1 commit
  31. 14 Nov, 2014 1 commit