1. 12 Nov, 2019 1 commit
  2. 13 Sep, 2019 1 commit
  3. 11 Sep, 2019 1 commit
  4. 10 Sep, 2019 2 commits
  5. 17 Aug, 2019 1 commit
    • Ido Schimmel's avatar
      devlink: Add packet trap infrastructure · 0f420b6c
      Ido Schimmel authored
      
      
      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: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f420b6c
  6. 09 Jul, 2019 2 commits
    • Parav Pandit's avatar
      devlink: Introduce PCI VF port flavour and port attribute · e41b6bf3
      Parav Pandit authored
      
      
      In an eswitch, PCI VF may have port which is normally represented using
      a representor netdevice.
      To have better visibility of eswitch port, its association with VF,
      and its representor netdevice, introduce a PCI VF port flavour.
      
      When devlink port flavour is PCI VF, fill up PCI VF attributes of
      the port.
      
      Extend port name creation using PCI PF and VF number scheme on best
      effort basis, so that vendor drivers can skip defining their own scheme.
      
      $ devlink port show
      pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
      pci/0000:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
      pci/0000:05:00.0/2: type eth netdev eth2 flavour pcivf pfnum 0 vfnum 1
      
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e41b6bf3
    • Parav Pandit's avatar
      devlink: Introduce PCI PF port flavour and port attribute · 98fd2d65
      Parav Pandit authored
      
      
      In an eswitch, PCI PF may have port which is normally represented
      using a representor netdevice.
      To have better visibility of eswitch port, its association with
      PF and a representor netdevice, introduce a PCI PF port
      flavour and port attriute.
      
      When devlink port flavour is PCI PF, fill up PCI PF attributes of the
      port.
      
      Extend port name creation using PCI PF number on best effort basis.
      So that vendor drivers can skip defining their own scheme.
      
      $ devlink port show
      pci/0000:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
      
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98fd2d65
  7. 04 Jun, 2019 1 commit
  8. 21 Feb, 2019 1 commit
  9. 17 Feb, 2019 1 commit
    • Jakub Kicinski's avatar
      devlink: add flash update command · 76726ccb
      Jakub Kicinski authored
      
      
      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: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76726ccb
  10. 07 Feb, 2019 6 commits
  11. 03 Feb, 2019 1 commit
  12. 01 Feb, 2019 2 commits
    • Jakub Kicinski's avatar
      devlink: add version reporting to devlink info API · fc6fae7d
      Jakub Kicinski authored
      
      
      ethtool -i has a few fixed-size fields which can be used to report
      firmware version and expansion ROM version. Unfortunately, modern
      hardware has more firmware components. There is usually some
      datapath microcode, management controller, PXE drivers, and a
      CPLD load. Running ethtool -i on modern controllers reveals the
      fact that vendors cram multiple values into firmware version field.
      
      Here are some examples from systems I could lay my hands on quickly:
      
      tg3:  "FFV20.2.17 bc 5720-v1.39"
      i40e: "6.01 0x800034a4 1.1747.0"
      nfp:  "0.0.3.5 0.25 sriov-2.1.16 nic"
      
      Add a new devlink API to allow retrieving multiple versions, and
      provide user-readable name for those versions.
      
      While at it break down the versions into three categories:
       - fixed - this is the board/fixed component version, usually vendors
                 report information like the board version in the PCI VPD,
                 but it will benefit from naming and common API as well;
       - running - this is the running firmware version;
       - stored - this is firmware in the flash, after firmware update
                  this value will reflect the flashed version, while the
                  running version may only be updated after reboot.
      
      v3:
       - add per-type helpers instead of using the special argument (Jiri).
      RFCv2:
       - remove the nesting in attr DEVLINK_ATTR_INFO_VERSIONS (now
         versions are mixed with other info attrs)l
       - have the driver report versions from the same callback as
         other info.
      
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc6fae7d
    • Jakub Kicinski's avatar
      devlink: add device information API · f9cf2288
      Jakub Kicinski authored
      
      
      ethtool -i has served us well for a long time, but its showing
      its limitations more and more. The device information should
      also be reported per device not per-netdev.
      
      Lay foundation for a simple devlink-based way of reading device
      info. Add driver name and device serial number as initial pieces
      of information exposed via this new API.
      
      v3:
       - rename helpers (Jiri);
       - rename driver name attr (Jiri);
       - remove double spacing in commit message (Jiri).
      RFC v2:
       - wrap the skb into an opaque structure (Jiri);
       - allow the serial number of be any length (Jiri & Andrew);
       - add driver name (Jonathan).
      
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9cf2288
  13. 30 Jan, 2019 3 commits
  14. 25 Jan, 2019 1 commit
  15. 18 Jan, 2019 6 commits
  16. 03 Dec, 2018 1 commit
  17. 13 Jul, 2018 4 commits
  18. 05 Jul, 2018 4 commits
  19. 19 May, 2018 1 commit