1. 27 3月, 2020 4 次提交
    • J
      devlink: track snapshot id usage count using an xarray · 12102436
      Jacob Keller 提交于
      Each snapshot created for a devlink region must have an id. These ids
      are supposed to be unique per "event" that caused the snapshot to be
      created. Drivers call devlink_region_snapshot_id_get to obtain a new id
      to use for a new event trigger. The id values are tracked per devlink,
      so that the same id number can be used if a triggering event creates
      multiple snapshots on different regions.
      
      There is no mechanism for snapshot ids to ever be reused. Introduce an
      xarray to store the count of how many snapshots are using a given id,
      replacing the snapshot_id field previously used for picking the next id.
      
      The devlink_region_snapshot_id_get() function will use xa_alloc to
      insert an initial value of 1 value at an available slot between 0 and
      U32_MAX.
      
      The new __devlink_snapshot_id_increment() and
      __devlink_snapshot_id_decrement() functions will be used to track how
      many snapshots currently use an id.
      
      Drivers must now call devlink_snapshot_id_put() in order to release
      their reference of the snapshot id after adding region snapshots.
      
      By tracking the total number of snapshots using a given id, it is
      possible for the decrement() function to erase the id from the xarray
      when it is not in use.
      
      With this method, a snapshot id can become reused again once all
      snapshots that referred to it have been deleted via
      DEVLINK_CMD_REGION_DEL, and the driver has finished adding snapshots.
      
      This work also paves the way to introduce a mechanism for userspace to
      request a snapshot.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12102436
    • J
      devlink: report error once U32_MAX snapshot ids have been used · 7ef19d3b
      Jacob Keller 提交于
      The devlink_snapshot_id_get() function returns a snapshot id. The
      snapshot id is a u32, so there is no way to indicate an error code.
      
      A future change is going to possibly add additional cases where this
      function could fail. Refactor the function to return the snapshot id in
      an argument, so that it can return zero or an error value.
      
      This ensures that snapshot ids cannot be confused with error values, and
      aids in the future refactor of snapshot id allocation management.
      
      Because there is no current way to release previously used snapshot ids,
      add a simple check ensuring that an error is reported in case the
      snapshot_id would over flow.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ef19d3b
    • J
      devlink: convert snapshot destructor callback to region op · a0a09f6b
      Jacob Keller 提交于
      It does not makes sense that two snapshots for a given region would use
      different destructors. Simplify snapshot creation by adding
      a .destructor op for regions.
      
      This operation will replace the data_destructor for the snapshot
      creation, and makes snapshot creation easier.
      Noticed-by: NJakub Kicinski <kuba@kernel.org>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0a09f6b
    • J
      devlink: prepare to support region operations · e8937681
      Jacob Keller 提交于
      Modify the devlink region code in preparation for adding new operations
      on regions.
      
      Create a devlink_region_ops structure, and move the name pointer from
      within the devlink_region structure into the ops structure (similar to
      the devlink_health_reporter_ops).
      
      This prepares the regions to enable support of additional operations in
      the future such as requesting snapshots, or accessing the region
      directly without a snapshot.
      
      In order to re-use the constant strings in the mlx4 driver their
      declaration must be changed to 'const char * const' to ensure the
      compiler realizes that both the data and the pointer cannot change.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8937681
  2. 24 3月, 2020 2 次提交
  3. 21 3月, 2020 1 次提交
  4. 26 2月, 2020 2 次提交
  5. 25 2月, 2020 1 次提交
  6. 19 2月, 2020 1 次提交
  7. 27 1月, 2020 1 次提交
  8. 19 1月, 2020 3 次提交
  9. 12 1月, 2020 1 次提交
  10. 11 1月, 2020 2 次提交
  11. 09 1月, 2020 1 次提交
  12. 13 11月, 2019 1 次提交
  13. 12 11月, 2019 1 次提交
  14. 10 11月, 2019 1 次提交
  15. 09 11月, 2019 1 次提交
  16. 08 11月, 2019 2 次提交
  17. 12 10月, 2019 1 次提交
  18. 06 10月, 2019 1 次提交
  19. 05 10月, 2019 2 次提交
  20. 14 9月, 2019 2 次提交
  21. 11 9月, 2019 1 次提交
  22. 05 9月, 2019 1 次提交
  23. 01 9月, 2019 1 次提交
  24. 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
  25. 10 8月, 2019 1 次提交
  26. 10 7月, 2019 2 次提交
    • P
      devlink: Introduce PCI VF port flavour and port attribute · e41b6bf3
      Parav Pandit 提交于
      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: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e41b6bf3
    • P
      devlink: Introduce PCI PF port flavour and port attribute · 98fd2d65
      Parav Pandit 提交于
      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: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98fd2d65