1. 14 7月, 2020 1 次提交
  2. 27 2月, 2020 1 次提交
  3. 18 2月, 2020 1 次提交
  4. 31 5月, 2019 1 次提交
  5. 02 3月, 2019 1 次提交
  6. 28 2月, 2019 2 次提交
  7. 25 2月, 2019 1 次提交
  8. 07 2月, 2019 1 次提交
  9. 18 1月, 2019 1 次提交
  10. 13 12月, 2018 3 次提交
  11. 24 11月, 2018 3 次提交
    • P
      switchdev: Replace port obj add/del SDO with a notification · d17d9f5e
      Petr Machata 提交于
      Drop switchdev_ops.switchdev_port_obj_add and _del. Drop the uses of
      this field from all clients, which were migrated to use switchdev
      notification in the previous patches.
      
      Add a new function switchdev_port_obj_notify() that sends the switchdev
      notifications SWITCHDEV_PORT_OBJ_ADD and _DEL.
      
      Update switchdev_port_obj_del_now() to dispatch to this new function.
      Drop __switchdev_port_obj_add() and update switchdev_port_obj_add()
      likewise.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d17d9f5e
    • P
      switchdev: Add helpers to aid traversal through lower devices · f30f0601
      Petr Machata 提交于
      After the transition from switchdev operations to notifier chain (which
      will take place in following patches), the onus is on the driver to find
      its own devices below possible layer of LAG or other uppers.
      
      The logic to do so is fairly repetitive: each driver is looking for its
      own devices among the lowers of the notified device. For those that it
      finds, it calls a handler. To indicate that the event was handled,
      struct switchdev_notifier_port_obj_info.handled is set. The differences
      lie only in what constitutes an "own" device and what handler to call.
      
      Therefore abstract this logic into two helpers,
      switchdev_handle_port_obj_add() and switchdev_handle_port_obj_del(). If
      a driver only supports physical ports under a bridge device, it will
      simply avoid this layer of indirection.
      
      One area where this helper diverges from the current switchdev behavior
      is the case of mixed lowers, some of which are switchdev ports and some
      of which are not. Previously, such scenario would fail with -EOPNOTSUPP.
      The helper could do that for lowers for which the passed-in predicate
      doesn't hold. That would however break the case that switchdev ports
      from several different drivers are stashed under one master, a scenario
      that switchdev currently happily supports. Therefore tolerate any and
      all unknown netdevices, whether they are backed by a switchdev driver
      or not.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f30f0601
    • P
      switchdev: Add a blocking notifier chain · a93e3b17
      Petr Machata 提交于
      In general one can't assume that a switchdev notifier is called in a
      non-atomic context, and correspondingly, the switchdev notifier chain is
      an atomic one.
      
      However, port object addition and deletion messages are delivered from a
      process context. Even the MDB addition messages, whose delivery is
      scheduled from atomic context, are queued and the delivery itself takes
      place in blocking context. For VLAN messages in particular, keeping the
      blocking nature is important for error reporting.
      
      Therefore introduce a blocking notifier chain and related service
      functions to distribute the notifications for which a blocking context
      can be assumed.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a93e3b17
  12. 10 11月, 2017 1 次提交
  13. 08 8月, 2017 2 次提交
  14. 09 6月, 2017 1 次提交
  15. 14 4月, 2017 1 次提交
  16. 30 10月, 2016 1 次提交
  17. 19 10月, 2016 1 次提交
    • I
      switchdev: Execute bridge ndos only for bridge ports · 97c24290
      Ido Schimmel 提交于
      We recently got the following warning after setting up a vlan device on
      top of an offloaded bridge and executing 'bridge link':
      
      WARNING: CPU: 0 PID: 18566 at drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:81 mlxsw_sp_port_orig_get.part.9+0x55/0x70 [mlxsw_spectrum]
      [...]
       CPU: 0 PID: 18566 Comm: bridge Not tainted 4.8.0-rc7 #1
       Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015
        0000000000000286 00000000e64ab94f ffff880406e6f8f0 ffffffff8135eaa3
        0000000000000000 0000000000000000 ffff880406e6f930 ffffffff8108c43b
        0000005106e6f988 ffff8803df398840 ffff880403c60108 ffff880406e6f990
       Call Trace:
        [<ffffffff8135eaa3>] dump_stack+0x63/0x90
        [<ffffffff8108c43b>] __warn+0xcb/0xf0
        [<ffffffff8108c56d>] warn_slowpath_null+0x1d/0x20
        [<ffffffffa01420d5>] mlxsw_sp_port_orig_get.part.9+0x55/0x70 [mlxsw_spectrum]
        [<ffffffffa0142195>] mlxsw_sp_port_attr_get+0xa5/0xb0 [mlxsw_spectrum]
        [<ffffffff816f151f>] switchdev_port_attr_get+0x4f/0x140
        [<ffffffff816f15d0>] switchdev_port_attr_get+0x100/0x140
        [<ffffffff816f15d0>] switchdev_port_attr_get+0x100/0x140
        [<ffffffff816f1d6b>] switchdev_port_bridge_getlink+0x5b/0xc0
        [<ffffffff816f2680>] ? switchdev_port_fdb_dump+0x90/0x90
        [<ffffffff815f5427>] rtnl_bridge_getlink+0xe7/0x190
        [<ffffffff8161a1b2>] netlink_dump+0x122/0x290
        [<ffffffff8161b0df>] __netlink_dump_start+0x15f/0x190
        [<ffffffff815f5340>] ? rtnl_bridge_dellink+0x230/0x230
        [<ffffffff815fab46>] rtnetlink_rcv_msg+0x1a6/0x220
        [<ffffffff81208118>] ? __kmalloc_node_track_caller+0x208/0x2c0
        [<ffffffff815f5340>] ? rtnl_bridge_dellink+0x230/0x230
        [<ffffffff815fa9a0>] ? rtnl_newlink+0x890/0x890
        [<ffffffff8161cf54>] netlink_rcv_skb+0xa4/0xc0
        [<ffffffff815f56f8>] rtnetlink_rcv+0x28/0x30
        [<ffffffff8161c92c>] netlink_unicast+0x18c/0x240
        [<ffffffff8161ccdb>] netlink_sendmsg+0x2fb/0x3a0
        [<ffffffff815c5a48>] sock_sendmsg+0x38/0x50
        [<ffffffff815c6031>] SYSC_sendto+0x101/0x190
        [<ffffffff815c7111>] ? __sys_recvmsg+0x51/0x90
        [<ffffffff815c6b6e>] SyS_sendto+0xe/0x10
        [<ffffffff817017f2>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      The problem is that the 8021q module propagates the call to
      ndo_bridge_getlink() via switchdev ops, but the switch driver doesn't
      recognize the netdev, as it's not offloaded.
      
      While we can ignore calls being made to non-bridge ports inside the
      driver, a better fix would be to push this check up to the switchdev
      layer.
      
      Note that these ndos can be called for non-bridged netdev, but this only
      happens in certain PF drivers which don't call the corresponding
      switchdev functions anyway.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NTamir Winetroub <tamirw@mellanox.com>
      Tested-by: NTamir Winetroub <tamirw@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97c24290
  18. 28 9月, 2016 2 次提交
  19. 02 9月, 2016 1 次提交
    • R
      rtnetlink: fdb dump: optimize by saving last interface markers · d297653d
      Roopa Prabhu 提交于
      fdb dumps spanning multiple skb's currently restart from the first
      interface again for every skb. This results in unnecessary
      iterations on the already visited interfaces and their fdb
      entries. In large scale setups, we have seen this to slow
      down fdb dumps considerably. On a system with 30k macs we
      see fdb dumps spanning across more than 300 skbs.
      
      To fix the problem, this patch replaces the existing single fdb
      marker with three markers: netdev hash entries, netdevs and fdb
      index to continue where we left off instead of restarting from the
      first netdev. This is consistent with link dumps.
      
      In the process of fixing the performance issue, this patch also
      re-implements fix done by
      commit 472681d5 ("net: ndo_fdb_dump should report -EMSGSIZE to rtnl_fdb_dump")
      (with an internal fix from Wilson Kok) in the following ways:
      - change ndo_fdb_dump handlers to return error code instead
      of the last fdb index
      - use cb->args strictly for dump frag markers and not error codes.
      This is consistent with other dump functions.
      
      Below results were taken on a system with 1000 netdevs
      and 35085 fdb entries:
      before patch:
      $time bridge fdb show | wc -l
      15065
      
      real    1m11.791s
      user    0m0.070s
      sys 1m8.395s
      
      (existing code does not return all macs)
      
      after patch:
      $time bridge fdb show | wc -l
      35085
      
      real    0m2.017s
      user    0m0.113s
      sys 0m1.942s
      Signed-off-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d297653d
  20. 27 8月, 2016 2 次提交
    • I
      bridge: switchdev: Add forward mark support for stacked devices · 6bc506b4
      Ido Schimmel 提交于
      switchdev_port_fwd_mark_set() is used to set the 'offload_fwd_mark' of
      port netdevs so that packets being flooded by the device won't be
      flooded twice.
      
      It works by assigning a unique identifier (the ifindex of the first
      bridge port) to bridge ports sharing the same parent ID. This prevents
      packets from being flooded twice by the same switch, but will flood
      packets through bridge ports belonging to a different switch.
      
      This method is problematic when stacked devices are taken into account,
      such as VLANs. In such cases, a physical port netdev can have upper
      devices being members in two different bridges, thus requiring two
      different 'offload_fwd_mark's to be configured on the port netdev, which
      is impossible.
      
      The main problem is that packet and netdev marking is performed at the
      physical netdev level, whereas flooding occurs between bridge ports,
      which are not necessarily port netdevs.
      
      Instead, packet and netdev marking should really be done in the bridge
      driver with the switch driver only telling it which packets it already
      forwarded. The bridge driver will mark such packets using the mark
      assigned to the ingress bridge port and will prevent the packet from
      being forwarded through any bridge port sharing the same mark (i.e.
      having the same parent ID).
      
      Remove the current switchdev 'offload_fwd_mark' implementation and
      instead implement the proposed method. In addition, make rocker - the
      sole user of the mark - use the proposed method.
      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>
      6bc506b4
    • I
      switchdev: Support parent ID comparison for stacked devices · 5c326ab4
      Ido Schimmel 提交于
      switchdev_port_same_parent_id() currently expects port netdevs, but we
      need it to support stacked devices in the next patch, so drop the
      NO_RECURSE flag.
      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>
      5c326ab4
  21. 16 8月, 2016 1 次提交
  22. 15 7月, 2016 1 次提交
  23. 18 5月, 2016 1 次提交
  24. 25 4月, 2016 1 次提交
  25. 25 3月, 2016 1 次提交
  26. 27 2月, 2016 1 次提交
  27. 29 1月, 2016 1 次提交
    • I
      switchdev: Require RTNL mutex to be held when sending FDB notifications · 4f2c6ae5
      Ido Schimmel 提交于
      When switchdev drivers process FDB notifications from the underlying
      device they resolve the netdev to which the entry points to and notify
      the bridge using the switchdev notifier.
      
      However, since the RTNL mutex is not held there is nothing preventing
      the netdev from disappearing in the middle, which will cause
      br_switchdev_event() to dereference a non-existing netdev.
      
      Make switchdev drivers hold the lock at the beginning of the
      notification processing session and release it once it ends, after
      notifying the bridge.
      
      Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
      when RTNL mutex is held.
      
      Fixes: 03bf0c28 ("switchdev: introduce switchdev notifier")
      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>
      4f2c6ae5
  28. 11 1月, 2016 1 次提交
  29. 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
  30. 04 11月, 2015 1 次提交
  31. 30 10月, 2015 2 次提交