From: Petr Machata <petrm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
<edumazet@google.com>, <pabeni@redhat.com>,
<andrew+netdev@lunn.ch>, <horms@kernel.org>, <shuah@kernel.org>,
<willemb@google.com>, <petrm@nvidia.com>,
<donald.hunter@gmail.com>, <michael.chan@broadcom.com>,
<pavan.chebbi@broadcom.com>, <linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net-next v2 3/9] tools: ynltool: add qstats analysis for HW-GRO efficiency / savings
Date: Mon, 9 Feb 2026 10:43:33 +0100 [thread overview]
Message-ID: <87o6lyz1xx.fsf@nvidia.com> (raw)
In-Reply-To: <20260207003509.3927744-4-kuba@kernel.org>
Jakub Kicinski <kuba@kernel.org> writes:
> 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.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
next prev parent reply other threads:[~2026-02-09 9:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 0:35 [PATCH net-next v2 0/9] net: stats, tools, driver tests for HW GRO Jakub Kicinski
2026-02-07 0:35 ` [PATCH net-next v2 1/9] eth: bnxt: gather and report HW-GRO stats Jakub Kicinski
2026-02-08 0:09 ` Michael Chan
2026-02-08 0:09 ` Michael Chan
2026-02-11 1:51 ` Jakub Kicinski
2026-02-07 0:35 ` [PATCH net-next v2 2/9] tools: ynltool: factor out qstat dumping Jakub Kicinski
2026-02-07 0:35 ` [PATCH net-next v2 3/9] tools: ynltool: add qstats analysis for HW-GRO efficiency / savings Jakub Kicinski
2026-02-09 9:43 ` Petr Machata [this message]
2026-02-07 0:35 ` [PATCH net-next v2 4/9] selftests: net: move gro to lib for HW vs SW reuse Jakub Kicinski
2026-02-09 2:36 ` Willem de Bruijn
2026-02-07 0:35 ` [PATCH net-next v2 5/9] selftests: drv-net: give HW stats sync time extra 25% of margin Jakub Kicinski
2026-02-09 2:37 ` Willem de Bruijn
2026-02-07 0:35 ` [PATCH net-next v2 6/9] selftests: drv-net: gro: use SO_TXTIME to schedule packets together Jakub Kicinski
2026-02-09 2:39 ` Willem de Bruijn
2026-02-11 1:56 ` Jakub Kicinski
2026-02-11 3:15 ` Willem de Bruijn
2026-02-11 3:48 ` Jakub Kicinski
2026-02-11 4:21 ` Willem de Bruijn
2026-02-11 17:00 ` Jakub Kicinski
2026-02-11 17:22 ` Willem de Bruijn
2026-02-07 0:35 ` [PATCH net-next v2 7/9] selftests: drv-net: gro: test GRO stats Jakub Kicinski
2026-02-07 0:35 ` [PATCH net-next v2 8/9] selftests: drv-net: gro: add test for packet ordering Jakub Kicinski
2026-02-07 0:35 ` [PATCH net-next v2 9/9] selftests: drv-net: gro: add a test for GRO depth Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o6lyz1xx.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=shuah@kernel.org \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.