From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: netdev-bot+sashiko@kernel.org, willemdebruijn.kernel@gmail.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
andrew+netdev@lunn.ch, willemb@google.com
Subject: Re: [PATCH net-next v8 3/6] idpf: support pacing offload
Date: Fri, 04 Sep 2026 11:22:48 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.253530bc7052@gmail.com> (raw)
In-Reply-To: <178848118375.4131868.13506511829846201867@kernel.org>
netdev-bot+sashiko@ wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> - [Medium] Divergent EDT state across a hard reset: the netdev-side
> pacing horizon survives while the adapter-side timestamp granularity…
The main AI feedback to this series continues to be that the
offload_horizon can remain set after a device reset would modify the
max_offload_horizon. That is mentioned as a known caveat in the
commit message. But indeed we can do better.
For v9
- I will reset the device offload_horizon here as suggested:
Disable offload_horizon if the new max_offload_horizon is lower.
- Am considering a device notifier in FQ to do the same for
q->offload_horizon.
Having both a configurable dev->offload_horizon and q->offload_horizon
is perhaps overkill. But we need the new dev one to safely roll out
the idpf feature default off. We cannot rely on FQ alone, as there are
other paths to pass packets with txtime to the driver: SO_TXTIME, BPF,
ETF.
For the other feedback, also for v9:
- Will restrict the 'expect_fail = None' to the new tests that need it.
- Will address the few other low severity points.
next prev parent reply other threads:[~2026-09-04 15:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 18:17 [PATCH net-next v8 0/6] hardware pacing offload Willem de Bruijn
2026-09-02 18:17 ` [PATCH net-next v8 1/6] net: rtnetlink: add pacing_offload_horizon attribute to net_device Willem de Bruijn
2026-09-04 0:19 ` netdev-bot+sashiko
2026-09-02 18:17 ` [PATCH net-next v8 2/6] net_sched: sch_fq: clear past skb->tstamp if offloading pacing Willem de Bruijn
2026-09-02 18:17 ` [PATCH net-next v8 3/6] idpf: support pacing offload Willem de Bruijn
2026-09-04 0:19 ` netdev-bot+sashiko
2026-09-04 15:22 ` Willem de Bruijn [this message]
2026-09-02 18:17 ` [PATCH net-next v8 4/6] selftests: drv-net: refactor so_txtime errqueue handling Willem de Bruijn
2026-09-04 0:19 ` netdev-bot+sashiko
2026-09-02 18:17 ` [PATCH net-next v8 5/6] selftests: drv-net: in so_txtime tell apart sw from hw pacing Willem de Bruijn
2026-09-04 0:19 ` netdev-bot+sashiko
2026-09-02 18:17 ` [PATCH net-next v8 6/6] selftests: drv-net: extend so_txtime with hw offload Willem de Bruijn
2026-09-04 0:19 ` netdev-bot+sashiko
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=willemdebruijn.kernel.253530bc7052@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox