1. 09 2月, 2021 1 次提交
  2. 02 12月, 2020 1 次提交
  3. 16 9月, 2020 1 次提交
  4. 15 7月, 2020 1 次提交
  5. 02 6月, 2020 2 次提交
  6. 23 5月, 2020 1 次提交
  7. 28 4月, 2020 1 次提交
    • H
      switchdev: mrp: Extend switchdev API to offload MRP · c284b545
      Horatiu Vultur 提交于
      Extend switchdev API to add support for MRP. The HW is notified in
      following cases:
      
      SWITCHDEV_OBJ_ID_MRP: This is used when a MRP instance is added/removed
        from the MRP ring.
      
      SWITCHDEV_OBJ_ID_RING_ROLE_MRP: This is used when the role of the node
        changes. The current supported roles are MRM and MRC.
      
      SWITCHDEV_OBJ_ID_RING_TEST_MRP: This is used when to start/stop sending
        MRP_Test frames on the mrp ring ports. This is called only on nodes that have
        the role MRM. In case this fails then the SW will generate the frames.
      
      SWITCHDEV_OBJ_ID_RING_STATE_STATE: This is used when the ring changes it states
        to open or closed. This is required to notify HW because the MRP_Test frame
        contains the field MRP_InState which contains this information.
      
      SWITCHDEV_ATTR_ID_MRP_PORT_STATE: This is used when the port's state is
        changed. It can be in blocking/forwarding mode.
      
      SWITCHDEV_ATTR_ID_MRP_PORT_ROLE: This is used when port's role changes. The
        roles of the port can be primary/secondary. This is required to notify HW
        because the MRP_Test frame contains the field MRP_PortRole that contains this
        information.
      Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c284b545
  8. 31 5月, 2019 1 次提交
  9. 02 3月, 2019 1 次提交
  10. 28 2月, 2019 2 次提交
  11. 25 2月, 2019 1 次提交
  12. 22 2月, 2019 3 次提交
  13. 07 2月, 2019 1 次提交
  14. 18 1月, 2019 1 次提交
  15. 13 12月, 2018 3 次提交
  16. 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
  17. 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
  18. 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
  19. 04 5月, 2018 1 次提交
  20. 10 11月, 2017 1 次提交
  21. 10 10月, 2017 1 次提交
  22. 08 8月, 2017 2 次提交
  23. 01 7月, 2017 1 次提交
  24. 09 6月, 2017 3 次提交
  25. 11 2月, 2017 1 次提交