You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our kstat framework today has a few shortcomings I bumped into while writing #1033. It would be useful if we had some abstractions which:
Allow us to attach one or more named kstat fields to an existing (installed) named kstat, assuming no others of the same name are registered.
Part of this is down to namespacing: when we create a Port, it takes the name opte$n. This prevents us from defining named stats which XDE cares about on a per-port basis, but OPTE itself does not know about.
Allow us to make use of the ks_update function pointer.
This would allow us to hold e.g., a single source of truth for counters and gauges in WIP: Flowstats #744.
This would also allow us to express some disaggregation of stats at runtime: a kstat might be filled out when needed based on sharded state, for instance.
Make use of other classes of kstat, non-virtual storage, etc. when appropriate.
Our kstat framework today has a few shortcomings I bumped into while writing #1033. It would be useful if we had some abstractions which:
Port, it takes the nameopte$n. This prevents us from defining named stats which XDE cares about on a per-port basis, but OPTE itself does not know about.ks_updatefunction pointer.