1. 05 10月, 2019 1 次提交
  2. 14 9月, 2019 2 次提交
  3. 11 9月, 2019 1 次提交
  4. 05 9月, 2019 1 次提交
  5. 01 9月, 2019 1 次提交
  6. 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
  7. 10 8月, 2019 1 次提交
  8. 10 7月, 2019 3 次提交
  9. 16 6月, 2019 1 次提交
  10. 05 6月, 2019 1 次提交
  11. 31 5月, 2019 1 次提交
  12. 24 5月, 2019 1 次提交
  13. 01 5月, 2019 1 次提交
  14. 23 4月, 2019 1 次提交
  15. 05 4月, 2019 3 次提交
  16. 29 3月, 2019 3 次提交
  17. 25 3月, 2019 2 次提交
  18. 05 3月, 2019 1 次提交
  19. 27 2月, 2019 2 次提交
  20. 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
  21. 13 2月, 2019 1 次提交
  22. 12 2月, 2019 1 次提交
  23. 09 2月, 2019 1 次提交
    • J
      devlink: publish params only after driver init is done · 7c62cfb8
      Jiri Pirko 提交于
      Currently, user can do dump or get of param values right after the
      devlink params are registered. However the driver may not be initialized
      which is an issue. The same problem happens during notification
      upon param registration. Allow driver to publish devlink params
      whenever it is ready to handle get() ops. Note that this cannot
      be resolved by init reordering, as the "driverinit" params have
      to be available before the driver is initialized (it needs the param
      values there).
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c62cfb8
  24. 08 2月, 2019 3 次提交
    • E
      devlink: Add health report functionality · c8e1da0b
      Eran Ben Elisha 提交于
      Upon error discover, every driver can report it to the devlink health
      mechanism via devlink_health_report function, using the appropriate
      reporter registered to it. Driver can pass error specific context which
      will be delivered to it as part of the dump / recovery callbacks.
      
      Once an error is reported, devlink health will do the following actions:
      * A log is being send to the kernel trace events buffer
      * Health status and statistics are being updated for the reporter instance
      * Object dump is being taken and stored at the reporter instance (as long
        as there is no other dump which is already stored)
      * Auto recovery attempt is being done. Depends on:
        - Auto Recovery configuration
        - Grace period vs. Time since last recover
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: NMoshe Shemesh <moshe@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8e1da0b
    • E
      devlink: Add health reporter create/destroy functionality · a0bdcc59
      Eran Ben Elisha 提交于
      Devlink health reporter is an instance for reporting, diagnosing and
      recovering from run time errors discovered by the reporters.
      Define it's data structure and supported operations.
      In addition, expose devlink API to create and destroy a reporter.
      Each devlink instance will hold it's own reporters list.
      
      As part of the allocation, driver shall provide a set of callbacks which
      will be used by devlink in order to handle health reports and user
      commands related to this reporter. In addition, driver is entitled to
      provide some priv pointer, which can be fetched from the reporter by
      devlink_health_reporter_priv function.
      
      For each reporter, devlink will hold a metadata of statistics,
      dump msg and status.
      
      For passing dumps and diagnose data to the user-space, it will use devlink
      fmsg API.
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: NMoshe Shemesh <moshe@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0bdcc59
    • E
      devlink: Add devlink formatted message (fmsg) API · 1db64e87
      Eran Ben Elisha 提交于
      Devlink fmsg is a mechanism to pass descriptors between drivers and
      devlink, in json-like format. The API allows the driver to add nested
      attributes such as object, object pair and value array, in addition to
      attributes such as name and value.
      
      Driver can use this API to fill the fmsg context in a format which will be
      translated by the devlink to the netlink message later.
      There is no memory allocation in advance (other than the initial list
      head), and it dynamically allocates messages descriptors and add them to
      the list on the fly.
      
      When it needs to send the data using SKBs to the netlink layer, it
      fragments the data between different SKBs. In order to do this
      fragmentation, it uses virtual nests attributes, to avoid actual
      nesting use which cannot be divided between different SKBs.
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: NMoshe Shemesh <moshe@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1db64e87
  25. 04 2月, 2019 1 次提交
  26. 02 2月, 2019 1 次提交