Re: [RFC net-next 2/6] selftests: net: py: add metric policy output

[Paolo Abeni <pabeni@redhat.com>]

On 9/16/26 21:04, Stanislav Fomichev wrote:
> +def ksft_metric_aggregate(name, summarize="total", *, aggregation=None,
> +                          transform=None, regression=None,
> +                          display_range=None, display_scale=None,
> +                          display_label=None):
> +    """Register processing and presentation metadata for a metric.
> +
> +    The policy applies to every observation with ``name`` in the current test
> +    case. It is emitted once as a ``ktap-metric-policy-json`` record before
> +    the matching ``ktap-metric-json`` observations, so a consumer can process
> +    the metric without recognizing its name. Register a policy before the
> +    first matching :func:`ksft_metric` call. Registering the same policy more
> +    than once is allowed; changing it or registering it after an observation
> +    is rejected.
> +
> +    Args:
> +        name: Metric name passed to :func:`ksft_metric`.
> +        summarize: Operation used to reduce the processed observations.
> +            Supported values are ``last``, ``total``, ``p50``, ``p90``,
> +            ``p99``, ``max``, and ``distribution``. ``distribution`` keeps
> +            ``last`` for one scalar observation and produces p50, p90, p99,
> +            and max for sampled observations. The default is ``total``.
> +        aggregation: Optional operation applied to each transformed
> +            observation before summarization. An aggregation may reduce a
> +            structured value, such as an array, to a scalar.
> +            ``busy-core-equivalents`` expects a CPU-indexed array and sums
> +            transformed per-CPU rates. Without a transform, it treats values
> +            as percentages and divides their sum by 100. The resulting series
> +            measures concurrently busy cores.
> +        transform: Optional operation applied before aggregation and summary.
> +            ``rate`` calculates ``(current - previous) / elapsed_time`` from
> +            timestamped cumulative observations. Counter decreases and
> +            intervals with nonpositive elapsed time do not produce a rate.

Very minor nit: I think sorting the above the arguments in the inverse
order would make understanding the doc easier (read order will match
data processing order).

/P