1. 29 Sep, 2015 1 commit
    • Nikolay Aleksandrov's avatar
      bridge: vlan: add per-vlan struct and move to rhashtables · 2594e906
      Nikolay Aleksandrov authored
      This patch changes the bridge vlan implementation to use rhashtables
      instead of bitmaps. The main motivation behind this change is that we
      need extensible per-vlan structures (both per-port and global) so more
      advanced features can be introduced and the vlan support can be
      extended. I've tried to break this up but the moment net_port_vlans is
      changed and the whole API goes away, thus this is a larger patch.
      A few short goals of this patch are:
      - Extensible per-vlan structs stored in rhashtables and a sorted list
      - Keep user-visible behaviour (compressed vlans etc)
      - Keep fastpath ingress/egress logic the same (optimizations to come
      Here's a brief list of some of the new features we'd like to introduce:
      - per-vlan counters
      - vlan ingress/egress mapping
      - per-vlan igmp configuration
      - vlan priorities
      - avoid fdb entries replication (e.g. local fdb scaling issues)
      The structure is kept single for both global and per-port entries so to
      avoid code duplication where possible and also because we'll soon introduce
      "port0 / aka bridge as port" which should simplify things further
      (thanks to Vlad for the suggestion!).
      Now we have per-vlan global rhashtable (bridge-wide) and per-vlan port
      rhashtable, if an entry is added to a port it'll get a pointer to its
      global context so it can be quickly accessed later. There's also a
      sorted vlan list which is used for stable walks and some user-visible
      behaviour such as the vlan ranges, also for error paths.
      VLANs are stored in a "vlan group" which currently contains the
      rhashtable, sorted vlan list and the number of "real" vlan entries.
      A good side-effect of this change is that it resembles how hw keeps
      per-vlan data.
      One important note after this change is that if a VLAN is being looked up
      in the bridge's rhashtable for filtering purposes (or to check if it's an
      existing usable entry, not just a global context) then the new helper
      br_vlan_should_use() needs to be used if the vlan is found. In case the
      lookup is done only with a port's vlan group, then this check can be
      Things tested so far:
      - basic vlan ingress/egress
      - pvids
      - untagged vlans
      - adding/deleting vlans in different scenarios (with/without global ctx,
        while transmitting traffic, in ranges etc)
      - loading/removing the module while having/adding/deleting vlans
      - extracting bridge vlan information (user ABI), compressed requests
      - adding/deleting fdbs on vlans
      - bridge mac change, promisc mode
      - default pvid change
      - kmemleak ON during the whole time
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 13 Jul, 2015 1 commit
  3. 12 Jan, 2015 1 commit
  4. 09 Dec, 2014 2 commits
  5. 03 Dec, 2014 1 commit
  6. 05 Nov, 2014 1 commit
  7. 02 Aug, 2013 1 commit
  8. 14 Feb, 2013 4 commits
  9. 16 Dec, 2012 1 commit
  10. 12 Dec, 2012 1 commit
  11. 07 Dec, 2012 1 commit
    • Cong Wang's avatar
      bridge: export multicast database via netlink · ee07c6e7
      Cong Wang authored
      V5: fix two bugs pointed out by Thomas
          remove seq check for now, mark it as TODO
      V4: remove some useless #include
          some coding style fix
      V3: drop debugging printk's
          update selinux perm table as well
      V2: drop patch 1/2, export ifindex directly
          Redesign netlink attributes
          Improve netlink seq check
          Handle IPv6 addr as well
      This patch exports bridge multicast database via netlink
      message type RTM_GETMDB. Similar to fdb, but currently bridge-specific.
      We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).
      (Thanks to Thomas for patient reviews)
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Graf <tgraf@suug.ch>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  12. 31 Oct, 2012 1 commit
    • John Fastabend's avatar
      net: set and query VEB/VEPA bridge mode via PF_BRIDGE · 2469ffd7
      John Fastabend authored
      Hardware switches may support enabling and disabling the
      loopback switch which puts the device in a VEPA mode defined
      in the IEEE 802.1Qbg specification. In this mode frames are
      not switched in the hardware but sent directly to the switch.
      SR-IOV capable NICs will likely support this mode I am
      aware of at least two such devices. Also I am told (but don't
      have any of this hardware available) that there are devices
      that only support VEPA modes. In these cases it is important
      at a minimum to be able to query these attributes.
      This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
      set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
      anticipating bridge attributes that may be common for both embedded
      bridges and software bridges this adds a flags attribute
      IFLA_BRIDGE_FLAGS currently used to determine if the command or event
      is being generated to/from an embedded bridge or software bridge.
      Finally, the event generation is pulled out of the bridge module and
      into rtnetlink proper.
      For example using the macvlan driver in VEPA mode on top of
      an embedded switch requires putting the embedded switch into
      a VEPA mode to get the expected results.
      	--------  --------
              | VEPA |  | VEPA |       <-- macvlan vepa edge relays
              --------  --------
                 |        |
                 |        |
              |      VEPA      |       <-- embedded switch in NIC
              | external switch |      <-- shiny new physical
      	-------------------          switch with VEPA support
      A packet sent from the macvlan VEPA at the top could be
      loopbacked on the embedded switch and never seen by the
      external switch. So in order for this to work the embedded
      switch needs to be set in the VEPA state via the above
      described commands.
      By making these attributes nested in IFLA_AF_SPEC we allow
      future extensions to be made as needed.
      CC: Lennert Buytenhek <buytenh@wantstofly.org>
      CC: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 13 Oct, 2012 1 commit
  14. 11 Jan, 2011 1 commit
  15. 15 Nov, 2010 1 commit
  16. 01 Jul, 2010 1 commit
  17. 14 Jun, 2010 1 commit
    • Paul E. McKenney's avatar
      net: Make accesses to ->br_port safe for sparse RCU · 81bdf5bd
      Paul E. McKenney authored
      The new versions of the rcu_dereference() APIs requires that any pointers
      passed to one of these APIs be fully defined.  The ->br_port field
      in struct net_device points to a struct net_bridge_port, which is an
      incomplete type.  This commit therefore changes ->br_port to be a void*,
      and introduces a br_port() helper function to convert the type to struct
      net_bridge_port, and applies this new helper function where required.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Stephen Hemminger <shemminger@linux-foundation.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
  18. 02 Jun, 2010 1 commit
  19. 04 Nov, 2009 1 commit
  20. 12 Jun, 2008 1 commit
  21. 02 May, 2008 1 commit
  22. 15 Oct, 2007 1 commit
  23. 10 Oct, 2007 1 commit
    • Eric W. Biederman's avatar
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman authored
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      were modified to take a network namespace argument, and
      deal with it.
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      For now the ifindex generator is left global.
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  24. 26 Apr, 2007 1 commit
  25. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!