RFC Dynamically extendable device counter support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 patches 2 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | ib core: Make device counter infrastructure dynamicdrivers/ drivers/ drivers/ +1 more | +300 | 0 replies | |
| 2/2 | mlx5: Sample code to exercise new device statisticsdrivers/ | +35 | 2 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 0/2] Dynamically extendable device counter support
We currently have issues when we want to expose device counters to the system because we have statically defined structures that define these counters. Changing these requires a change in the ABI since the counter structures are defined in ib_verbs.h.
Moreover it seems that these counter diverge in a device driver specific way. Counters show up in sysfs that are not supported by the device driver and that will always be zero.
The patches here change the ABI to avoid hardcoding counter names to the ABI. Instead of populated counters in structure predefined in ib_verbs.h we simply return a pointer to an array of strings describing the pointers supported and an array of values of these counters. That allows device drives to define an arbitrary amount of counters as needed. Adding a counter does not requrie changing ib_verbs.h.
IB device drivers can develop standard semantics for specific counters that are supported by multiple device drives by using the same names there. So software can just check if the device supports a certain counter and then expect the same behavior of that counter regardless of the device driver.
This patch series modifies the Iwarp device drives to support the proposed different way of handling things and then provides a simple sample on how the mlx5 driver could support counters.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html