1. 17 4月, 2016 1 次提交
    • H
      vxlan: synchronously and race-free destruction of vxlan sockets · 0412bd93
      Hannes Frederic Sowa 提交于
      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: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0412bd93
  2. 12 4月, 2016 1 次提交
  3. 08 4月, 2016 1 次提交
  4. 07 4月, 2016 3 次提交
    • J
      vxlan: implement GPE · e1e5314d
      Jiri Benc 提交于
      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: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1e5314d
    • J
      vxlan: move fdb code to common location in vxlan_xmit · 47e5d1b0
      Jiri Benc 提交于
      Handle VXLAN_F_COLLECT_METADATA before VXLAN_F_PROXY. The latter does not
      make sense with the former, as it needs populated fdb which does not happen
      in metadata mode.
      
      After this cleanup, the fdb code in vxlan_xmit is moved to a common location
      and can be later skipped for VXLAN-GPE which does not necessarily carry
      inner Ethernet header.
      
      v2: changed commit description to not reference L3 mode
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      47e5d1b0
    • J
      vxlan: move Ethernet initialization to a separate function · 0c867c9b
      Jiri Benc 提交于
      This will allow to initialize vxlan in ARPHRD_NONE mode based on the passed
      rtnl attributes.
      
      v2: renamed "l2mode" to "ether".
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c867c9b
  5. 22 3月, 2016 1 次提交
  6. 21 3月, 2016 1 次提交
  7. 14 3月, 2016 1 次提交
    • A
      gro: Defer clearing of flush bit in tunnel paths · c194cf93
      Alexander Duyck 提交于
      This patch updates the GRO handlers for GRE, VXLAN, GENEVE, and FOU so that
      we do not clear the flush bit until after we have called the next level GRO
      handler.  Previously this was being cleared before parsing through the list
      of frames, however this resulted in several paths where either the bit
      needed to be reset but wasn't as in the case of FOU, or cases where it was
      being set as in GENEVE.  By just deferring the clearing of the bit until
      after the next level protocol has been parsed we can avoid any unnecessary
      bit twiddling and avoid bugs.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c194cf93
  8. 12 3月, 2016 2 次提交
  9. 09 3月, 2016 2 次提交
  10. 05 3月, 2016 1 次提交
  11. 04 3月, 2016 1 次提交
  12. 27 2月, 2016 1 次提交
  13. 26 2月, 2016 5 次提交
  14. 22 2月, 2016 1 次提交
  15. 19 2月, 2016 5 次提交
  16. 18 2月, 2016 7 次提交
  17. 17 2月, 2016 2 次提交
  18. 12 2月, 2016 2 次提交
  19. 11 2月, 2016 1 次提交
  20. 10 2月, 2016 1 次提交
    • D
      vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices · 7e059158
      David Wragg 提交于
      Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
      transmit vxlan packets of any size, constrained only by the ability to
      send out the resulting packets.  4.3 introduced netdevs corresponding
      to tunnel vports.  These netdevs have an MTU, which limits the size of
      a packet that can be successfully encapsulated.  The default MTU
      values are low (1500 or less), which is awkwardly small in the context
      of physical networks supporting jumbo frames, and leads to a
      conspicuous change in behaviour for userspace.
      
      Instead, set the MTU on openvswitch-created netdevs to be the relevant
      maximum (i.e. the maximum IP packet size minus any relevant overhead),
      effectively restoring the behaviour prior to 4.3.
      Signed-off-by: NDavid Wragg <david@weave.works>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e059158