tools: ynltool: add qstats analysis for HW-GRO efficiency / savings

Extend ynltool to compute HW GRO savings metric - how many
packets has HW GRO been able to save the kernel from seeing.

Note that

tools: ynltool: add qstats analysis for HW-GRO efficiency / savings

Extend ynltool to compute HW GRO savings metric - how many
packets has HW GRO been able to save the kernel from seeing.

Note that this definition does not actually take into account
whether the segments were or weren't eligible for HW GRO.
If a machine is receiving all-UDP traffic - new metric will show
HW-GRO savings of 0%. Conversely since the super-packet still
counts as a received packet, savings of 100% is not achievable.
Perfect HW-GRO on a machine with 4k MTU and 64kB super-frames
would show ~93.75% savings. With 1.5k MTU we may see up to
~97.8% savings (if my math is right).

Example after 10 sec of iperf on a freshly booted machine
with 1.5k MTU:

$ ynltool qstats show
eth0 rx-packets: 40681280 rx-bytes: 61575208437
rx-alloc-fail: 0 rx-hw-gro-packets: 1225133
rx-hw-gro-wire-packets: 40656633
$ ynltool qstats hw-gro
eth0: 96.9% savings

None of the NICs I have access to can report "missed" HW-GRO
opportunities so computing a true "effectiveness" metric
is not possible. One could also argue that effectiveness metric
is inferior in environments where we control both senders and
receivers, the savings metrics will capture both regressions
in receiver's HW GRO effectiveness but also regressions in senders
sending smaller TSO trains. And we care about both. The main
downside is that it's hard to tell at a glance how well the NIC
is doing because the savings will be dependent on traffic patterns.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260207003509.3927744-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools: ynltool: factor out qstat dumping

The logic to open a socket and dump the queues is the same
across sub-commands. Factor it out, we'll need it again.

No functional changes intended.

Reviewe

tools: ynltool: factor out qstat dumping

The logic to open a socket and dump the queues is the same
across sub-commands. Factor it out, we'll need it again.

No functional changes intended.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260207003509.3927744-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...

tools/net/ynl: suppress jobserver warning in ynltool version detection

When building ynltool with parallel make (-jN), a warning is emitted:

make[1]: warning: jobserver unavailable: using -j1.

tools/net/ynl: suppress jobserver warning in ynltool version detection

When building ynltool with parallel make (-jN), a warning is emitted:

make[1]: warning: jobserver unavailable: using -j1.
Add '+' to parent make rule.

The warning trips up local runs of NIPA's ingest_mdir.py, which
correctly fails on make warnings.

This occurs because SRC_VERSION uses $(shell make ...) to make
kernelversion. The $(shell) function inherits make's MAKEFLAGS env var
which specifies "--jobserver-auth=R,W" pointing to file descriptors that
the invoked make sub-shell does not have access to.

Observed with:

$ make --version | head -1
GNU Make 4.3

Instead of suppressing MAKEFLAGS and foregoing all future MAKEFLAGS
(some of which may be desirable, such as variable overrides) or
introducing a new make target, we instead just ignore the warning by
piping stderr to /dev/null. If 'make kernelversion' fails, the ' || echo
"unknown"' phrase will catch the failure.

Before:
NIPA ingest_mdir.py:

ynl
Full series FAIL (1)
Generated files up to date; build has 1 warnings/errors; no diff in
generated;

After:
NIPA ingest_mdir.py:

Series level tests:
ynl OKAY

Validated output:
$ ./ynltool/ynltool --version
ynltool 6.19.0-rc4

Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260112-ynl-make-fix-v1-1-c399e76925ad@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

show more ...