1. 14 4月, 2016 1 次提交
    • X
      bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_br · 047831a9
      Xin Long 提交于
      Now when we change the attributes of bridge or br_port by netlink,
      a relevant netlink notification will be sent, but if we change them
      by ioctl or sysfs, no notification will be sent.
      
      We should ensure that whenever those attributes change internally or from
      sysfs/ioctl, that a netlink notification is sent out to listeners.
      
      Also, NetworkManager will use this in the future to listen for out-of-band
      bridge master attribute updates and incorporate them into the runtime
      configuration.
      
      This patch is used for br_sysfs_br. and we also need to remove some
      rtnl_trylock in old functions so that we can call it in a common one.
      
      For group_addr_store, we cannot make it use store_bridge_parm, because
      it's not a string-to-long convert, we will add notification on it
      individually.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      047831a9
  2. 19 2月, 2016 1 次提交
  3. 07 1月, 2016 2 次提交
  4. 16 12月, 2015 1 次提交
    • I
      switchdev: Pass original device to port netdev driver · 6ff64f6f
      Ido Schimmel 提交于
      switchdev drivers need to know the netdev on which the switchdev op was
      invoked. For example, the STP state of a VLAN interface configured on top
      of a port can change while being member in a bridge. In this case, the
      underlying driver should only change the STP state of that particular
      VLAN and not of all the VLANs configured on the port.
      
      However, current switchdev infrastructure only passes the port netdev down
      to the driver. Solve that by passing the original device down to the
      driver as part of the required switchdev object / attribute.
      
      This doesn't entail any change in current switchdev drivers. It simply
      enables those supporting stacked devices to know the originating device
      and act accordingly.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ff64f6f
  5. 03 11月, 2015 3 次提交
  6. 13 10月, 2015 4 次提交
  7. 12 10月, 2015 1 次提交
  8. 05 10月, 2015 5 次提交
  9. 03 10月, 2015 4 次提交
  10. 02 10月, 2015 5 次提交
  11. 30 9月, 2015 2 次提交
    • V
      net: switchdev: abstract object in add/del ops · ab069002
      Vivien Didelot 提交于
      Similar to the notifier_call callback of a notifier_block, change the
      function signature of switchdev add and del operations to:
      
          int switchdev_port_obj_add/del(struct net_device *dev,
                                         enum switchdev_obj_id id, void *obj);
      
      This allows the caller to pass a specific switchdev_obj_* structure
      instead of the generic switchdev_obj one.
      
      Drivers implementation of these operations and switchdev have been
      changed accordingly.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab069002
    • N
      bridge: vlan: add per-vlan struct and move to rhashtables · 2594e906
      Nikolay Aleksandrov 提交于
      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
        later)
      
      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
      skipped.
      
      Things tested so far:
      - basic vlan ingress/egress
      - pvids
      - untagged vlans
      - undef CONFIG_BRIDGE_VLAN_FILTERING
      - 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: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2594e906
  12. 09 9月, 2015 1 次提交
  13. 28 8月, 2015 1 次提交
  14. 11 8月, 2015 1 次提交
  15. 24 6月, 2015 1 次提交
  16. 23 6月, 2015 1 次提交
  17. 16 6月, 2015 1 次提交
    • S
      bridge: use either ndo VLAN ops or switchdev VLAN ops to install MASTER vlans · 7f109539
      Scott Feldman 提交于
      v2:
      
      Move struct switchdev_obj automatics to inner scope where there used.
      
      v1:
      
      To maintain backward compatibility with the existing iproute2 "bridge vlan"
      command, let bridge's setlink/dellink handler call into either the port
      driver's 8021q ndo ops or the port driver's bridge_setlink/dellink ops.
      
      This allows port driver to choose 8021q ops or the newer
      bridge_setlink/dellink ops when implementing VLAN add/del filtering on the
      device.  The iproute "bridge vlan" command does not need to be modified.
      
      To summarize using the "bridge vlan" command examples, we have:
      
      1) bridge vlan add|del vid VID dev DEV
      
      Here iproute2 sets MASTER flag.  Bridge's bridge_setlink/dellink is called.
      Vlan is set on bridge for port.  If port driver implements ndo 8021q ops,
      call those to port driver can install vlan filter on device.  Otherwise, if
      port driver implements bridge_setlink/dellink ops, call those to install
      vlan filter to device.  This option only works if port is bridged.
      
      2) bridge vlan add|del vid VID dev DEV master
      
      Same as 1)
      
      3) bridge vlan add|del vid VID dev DEV self
      
      Bridge's bridge_setlink/dellink isn't called.  Port driver's
      bridge_setlink/dellink is called, if implemented.  This option works if
      port is bridged or not.  If port is not bridged, a VLAN can still be
      added/deleted to device filter using this variant.
      
      4) bridge vlan add|del vid VID dev DEV master self
      
      This is a combination of 1) and 3), but will only work if port is bridged.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f109539
  18. 14 1月, 2015 1 次提交
  19. 22 11月, 2014 1 次提交
  20. 06 10月, 2014 3 次提交