1. 09 11月, 2019 1 次提交
  2. 08 11月, 2019 2 次提交
  3. 12 10月, 2019 1 次提交
  4. 06 10月, 2019 1 次提交
  5. 05 10月, 2019 2 次提交
  6. 14 9月, 2019 2 次提交
  7. 11 9月, 2019 1 次提交
  8. 05 9月, 2019 1 次提交
  9. 01 9月, 2019 1 次提交
  10. 18 8月, 2019 3 次提交
    • I
      Documentation: Add devlink-trap documentation · f3047ca0
      Ido Schimmel 提交于
      Add initial documentation of the devlink-trap mechanism, explaining the
      background, motivation and the semantics of the interface.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3047ca0
    • I
      devlink: Add generic packet traps and groups · 391203ab
      Ido Schimmel 提交于
      Add generic packet traps and groups that can report dropped packets as
      well as exceptions such as TTL error.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      391203ab
    • I
      devlink: Add packet trap infrastructure · 0f420b6c
      Ido Schimmel 提交于
      Add the basic packet trap infrastructure that allows device drivers to
      register their supported packet traps and trap groups with devlink.
      
      Each driver is expected to provide basic information about each
      supported trap, such as name and ID, but also the supported metadata
      types that will accompany each packet trapped via the trap. The
      currently supported metadata type is just the input port, but more will
      be added in the future. For example, output port and traffic class.
      
      Trap groups allow users to set the action of all member traps. In
      addition, users can retrieve per-group statistics in case per-trap
      statistics are too narrow. In the future, the trap group object can be
      extended with more attributes, such as policer settings which will limit
      the amount of traffic generated by member traps towards the CPU.
      
      Beside registering their packet traps with devlink, drivers are also
      expected to report trapped packets to devlink along with relevant
      metadata. devlink will maintain packets and bytes statistics for each
      packet trap and will potentially report the trapped packet with its
      metadata to user space via drop monitor netlink channel.
      
      The interface towards the drivers is simple and allows devlink to set
      the action of the trap. Currently, only two actions are supported:
      'trap' and 'drop'. When set to 'trap', the device is expected to provide
      the sole copy of the packet to the driver which will pass it to devlink.
      When set to 'drop', the device is expected to drop the packet and not
      send a copy to the driver. In the future, more actions can be added,
      such as 'mirror'.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f420b6c
  11. 10 8月, 2019 1 次提交
  12. 10 7月, 2019 3 次提交
  13. 16 6月, 2019 1 次提交
  14. 05 6月, 2019 1 次提交
  15. 31 5月, 2019 1 次提交
  16. 24 5月, 2019 1 次提交
  17. 01 5月, 2019 1 次提交
  18. 23 4月, 2019 1 次提交
  19. 05 4月, 2019 3 次提交
  20. 29 3月, 2019 3 次提交
  21. 25 3月, 2019 2 次提交
  22. 05 3月, 2019 1 次提交
  23. 27 2月, 2019 2 次提交
  24. 18 2月, 2019 2 次提交
    • J
      ethtool: add compat for flash update · 4eceba17
      Jakub Kicinski 提交于
      If driver does not support ethtool flash update operation
      call into devlink.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4eceba17
    • J
      devlink: add flash update command · 76726ccb
      Jakub Kicinski 提交于
      Add devlink flash update command. Advanced NICs have firmware
      stored in flash and often cryptographically secured. Updating
      that flash is handled by management firmware. Ethtool has a
      flash update command which served us well, however, it has two
      shortcomings:
       - it takes rtnl_lock unnecessarily - really flash update has
         nothing to do with networking, so using a networking device
         as a handle is suboptimal, which leads us to the second one:
       - it requires a functioning netdev - in case device enters an
         error state and can't spawn a netdev (e.g. communication
         with the device fails) there is no netdev to use as a handle
         for flashing.
      
      Devlink already has the ability to report the firmware versions,
      now with the ability to update the firmware/flash we will be
      able to recover devices in bad state.
      
      To enable updates of sub-components of the FW allow passing
      component name.  This name should correspond to one of the
      versions reported in devlink info.
      
      v1: - replace target id with component name (Jiri).
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76726ccb
  25. 13 2月, 2019 1 次提交
  26. 12 2月, 2019 1 次提交