From: Jakub Kicinski <kuba@kernel.org>
To: Pin-yen Lin <treapking@google.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
Taehee Yoo <ap420073@gmail.com>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
netdev@vger.kernel.org, Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] selftests: drv-net: ping: Wait for carrier after toggling offloads
Date: Wed, 18 Mar 2026 18:25:31 -0700 [thread overview]
Message-ID: <20260318182531.2e8bf837@kernel.org> (raw)
In-Reply-To: <CAHwYsirHq7PRWg-jeGz=+Yrn2Td=o3vBSXrjfPos57V0VQL6gA@mail.gmail.com>
On Wed, 18 Mar 2026 17:51:11 -0700 Pin-yen Lin wrote:
> > On Tue, 17 Mar 2026 18:01:17 -0700 Pin-yen Lin wrote:
> > > Toggling checksum offload (or HW-GRO via feature dependencies) can cause
> > > certain physical interfaces to undergo a reset or a temporary link-down
> > > state. In the ping.py test, this leads to immediate test failures if the
> > > ping is attempted before the carrier is restored.
> > >
> > > This is observed when running the test with GVE driver when HW-GRO is
> > > enabled. When checksum offload is toggled, HW-GRO is toggled as well
> > > because of the feature dependency. This leads to an interface reset,
> > > causing the subsequent ping to fail.
> > >
> > > Add a sleep period after changing these features to allow the link to
> > > stabilize.
> >
> > Sounds like the test found a legitimate problem. The configuration
> > should not return to user space until the operation has completed.
> > User should not have to sleep 10sec each time they touch NIC
> > configuration.
>
> To clarify, the configuration operation itself completes before
> returning to userspace. However, the short link-down during the
> configuration triggers asynchronous systemd events. These userspace
> operations affect the subsequent pings. Sorry for not making this
> clear in the commit message.
Can we somehow avoid / suppress this systemd behavior as part of
(your local) environment setup? Each environment will have some
setups steps. We assume that DAD is disabled, IPv6 addresses are
not flushed on ifdown, of course no firewalls..
prev parent reply other threads:[~2026-03-19 1:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 1:01 [PATCH net] selftests: drv-net: ping: Wait for carrier after toggling offloads Pin-yen Lin
2026-03-19 0:28 ` Jakub Kicinski
2026-03-19 0:51 ` Pin-yen Lin
2026-03-19 1:25 ` Jakub Kicinski [this message]
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=20260318182531.2e8bf837@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=ap420073@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=treapking@google.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