1. 22 2月, 2019 1 次提交
  2. 07 2月, 2019 1 次提交
  3. 18 1月, 2019 1 次提交
  4. 13 12月, 2018 3 次提交
  5. 24 11月, 2018 5 次提交
    • 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 SWITCHDEV_PORT_OBJ_ADD, SWITCHDEV_PORT_OBJ_DEL · aa4efe21
      Petr Machata 提交于
      An offloading driver may need to have access to switchdev events on
      ports that aren't directly under its control. An example is a VXLAN port
      attached to a bridge offloaded by a driver. The driver needs to know
      about VLANs configured on the VXLAN device. However the VXLAN device
      isn't stashed between the bridge and a front-panel-port device (such as
      is the case e.g. for LAG devices), so the usual switchdev ops don't
      reach the driver.
      
      VXLAN is likely not the only device type like this: in theory any L2
      tunnel device that needs offloading will prompt requirement of this
      sort. This falsifies the assumption that only the lower devices of a
      front panel port need to be notified to achieve flawless offloading.
      
      A way to fix this is to give up the notion of port object addition /
      deletion as a switchdev operation, which assumes somewhat tight coupling
      between the message producer and consumer. And instead send the message
      over a notifier chain.
      
      To that end, introduce two new switchdev notifier types,
      SWITCHDEV_PORT_OBJ_ADD and SWITCHDEV_PORT_OBJ_DEL. These notifier types
      communicate the same event as the corresponding switchdev op, except in
      a form of a notification. struct switchdev_notifier_port_obj_info was
      added to carry the fields that the switchdev op carries. An additional
      field, handled, will be used to communicate back to switchdev that the
      event has reached an interested party, which will be important for the
      two-phase commit.
      
      The two switchdev operations themselves are kept in place. Following
      patches first convert individual clients to the notifier protocol, and
      only then are the operations removed.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa4efe21
    • 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
    • P
      switchdev: SWITCHDEV_OBJ_PORT_{VLAN, MDB}(): Sanitize · ec394af5
      Petr Machata 提交于
      The two macros SWITCHDEV_OBJ_PORT_VLAN() and SWITCHDEV_OBJ_PORT_MDB()
      expand to a container_of() call, yielding an appropriate container of
      their sole argument. However, due to a name collision, the first
      argument, i.e. the contained object pointer, is not the only one to get
      expanded. The third argument, which is a structure member name, and
      should be kept literal, gets expanded as well. The only safe way to use
      these two macros is therefore to name the local variable passed to them
      "obj".
      
      To fix this, rename the sole argument of the two macros from
      "obj" (which collides with the member name) to "OBJ". Additionally,
      instead of passing "OBJ" to container_of() verbatim, parenthesize it, so
      that a comma in the passed-in expression doesn't pollute the
      container_of() invocation.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec394af5
  6. 22 11月, 2018 1 次提交
    • P
      vxlan: Add hardware FDB learning · 5728ae0d
      Petr Machata 提交于
      In order to allow devices to signal learning events to VXLAN, introduce
      two new switchdev messages: SWITCHDEV_VXLAN_FDB_ADD_TO_BRIDGE and
      SWITCHDEV_VXLAN_FDB_DEL_TO_BRIDGE.
      
      Listen to these notifications in the vxlan driver. The FDB entries
      learned this way have an NTF_EXT_LEARNED flag, and only entries marked
      as such can be unlearned by the _DEL_ event. They are also immediately
      marked as offloaded. This is the same behavior that the bridge driver
      observes.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5728ae0d
  7. 18 10月, 2018 3 次提交
    • I
      bridge: switchdev: Allow clearing FDB entry offload indication · e9ba0fbc
      Ido Schimmel 提交于
      Currently, an FDB entry only ceases being offloaded when it is deleted.
      This changes with VxLAN encapsulation.
      
      Devices capable of performing VxLAN encapsulation usually have only one
      FDB table, unlike the software data path which has two - one in the
      bridge driver and another in the VxLAN driver.
      
      Therefore, bridge FDB entries pointing to a VxLAN device are only
      offloaded if there is a corresponding entry in the VxLAN FDB.
      
      Allow clearing the offload indication in case the corresponding entry
      was deleted from the VxLAN FDB.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9ba0fbc
    • P
      vxlan: Support marking RDSTs as offloaded · 0efe1173
      Petr Machata 提交于
      Offloaded bridge FDB entries are marked with NTF_OFFLOADED. Implement a
      similar mechanism for VXLAN, where a given remote destination can be
      marked as offloaded.
      
      To that end, introduce a new event, SWITCHDEV_VXLAN_FDB_OFFLOADED,
      through which the marking is communicated to the vxlan driver. To
      identify which RDST should be marked as offloaded, an
      switchdev_notifier_vxlan_fdb_info is passed to the listeners. The
      "offloaded" flag in that object determines whether the offloaded mark
      should be set or cleared.
      
      When sending offloaded FDB entries over netlink, mark them with
      NTF_OFFLOADED.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0efe1173
    • P
      vxlan: Add switchdev notifications · 9a997353
      Petr Machata 提交于
      When offloading VXLAN devices, drivers need to know about events in
      VXLAN FDB database. Since VXLAN models a bridge, it is natural to
      distribute the VXLAN FDB notifications using the pre-existing switchdev
      notification mechanism.
      
      To that end, introduce two new notification types:
      SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE and SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE.
      Introduce a new function, vxlan_fdb_switchdev_call_notifiers() to send
      the new notifier types, and a struct switchdev_notifier_vxlan_fdb_info
      to communicate the details of the FDB entry under consideration.
      
      Invoke the new function from vxlan_fdb_notify().
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a997353
  8. 04 5月, 2018 1 次提交
  9. 10 11月, 2017 1 次提交
  10. 10 10月, 2017 1 次提交
  11. 08 8月, 2017 2 次提交
  12. 01 7月, 2017 1 次提交
  13. 09 6月, 2017 3 次提交
  14. 11 2月, 2017 2 次提交
  15. 28 9月, 2016 1 次提交
  16. 03 9月, 2016 1 次提交
  17. 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
  18. 27 8月, 2016 1 次提交
    • 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
  19. 20 7月, 2016 1 次提交
  20. 15 7月, 2016 1 次提交
  21. 18 5月, 2016 1 次提交
  22. 25 4月, 2016 1 次提交
  23. 11 1月, 2016 1 次提交
  24. 07 1月, 2016 1 次提交
  25. 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
  26. 17 11月, 2015 1 次提交
  27. 15 10月, 2015 2 次提交