From: Jakub Kicinski <kuba@kernel.org>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>
Cc: Bobby Eshleman <bobbyeshleman@gmail.com>,
Michael Chan <michael.chan@broadcom.com>,
davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch,
andrew.gospodarek@broadcom.com
Subject: Re: [PATCH net v2 4/4] selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up
Date: Tue, 10 Feb 2026 20:17:06 -0800 [thread overview]
Message-ID: <20260210201706.1da13881@kernel.org> (raw)
In-Reply-To: <CALs4sv3hca2N=+w9A81ZLMz9QCHqA7OzGFOzKGswd2sy+9zt7w@mail.gmail.com>
On Wed, 11 Feb 2026 09:28:22 +0530 Pavan Chebbi wrote:
> On Wed, Feb 11, 2026 at 7:16 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > > I checked and tried using the cmd() and it indeed eliminates a lot of
> > > lines here. But the test itself becomes a little unreliable.
> > > I often see TimeoutError: [Errno Wait for file contents failed]
> > > /sys/class/net/ens2f0np0/carrier from the wait_file (Jakub asked me to
> > > use wait_file)
> >
> > Does the link take more than the default 5 sec to come up?
> > wait_file() has a deadline param that should let us wait longer
>
> I did try with increased deadline. But I don't think it's helping.
If you check the carrier manually in a second terminal while it's
running -- do you see it go to 1? The helper keeps the file open
and rewinds to the start, I think that may not work with sysfs :S
Maybe we need:
diff --git a/tools/testing/selftests/net/lib/py/utils.py b/tools/testing/selftests/net/lib/py/utils.py
index 85884f3e827b..24e74475315d 100644
--- a/tools/testing/selftests/net/lib/py/utils.py
+++ b/tools/testing/selftests/net/lib/py/utils.py
@@ -294,11 +294,10 @@ GLOBAL_DEFER_ARMED = False
"""
end = time.monotonic() + deadline
- with open(fname, "r", encoding=encoding) as fp:
- while True:
+ while True:
+ with open(fname, "r", encoding=encoding) as fp:
if test_fn(fp.read()):
break
- fp.seek(0)
if time.monotonic() > end:
raise TimeoutError("Wait for file contents failed", fname)
time.sleep(sleep)
> > > Also, even when the test succeeds, after the suite exits, I cannot
> > > ping the remote host for a long time. In contrast, my manual loop
> > > worked 100pc of the times I tested.
> > > I am using the command like below:
> > >
> > > for _ in range(10):
> > > if cmd(f"ping -c 1 -W 1 {remote_addr}", fail=False, timeout=2).ret == 0:
> > > break
> > > time.sleep(1)
> > > else:
> > > raise KsftSkipEx("Cannot reach remote host after interface up")
> > >
> > > I am not a py expert so is there something I am missing?
> >
> > I don't think there's anything Python related here :(
>
> What I wanted to check was that if the cmd() invokes some shell and
> has some kind overhead that could affect timing..
>
> > Is it possible that NIC reports carrier before it can actually send
> > packets? Maybe the wait_file() gives ping has a higher chance of failing
> > with carrier up which makes the neighbor resolution failure more sticky?
>
> I am not sure. I am willing to send the manual ping loop version as I
> have high confidence on that.
> If you or Bobby insist I must use cmd() then I can spend more time on that..
cmd() doesn't do any magic, it basically does:
proc = subprocess.Popen(comm, shell=shell,
stdout=subprocess.PIPE, stderr=subprocess.PIPE,
pass_fds=pass_fds, env=env)
proc.communicate(timeout)
So pretty much the same code as your subprocess.run().
It has support for communicating with extra fds to
next prev parent reply other threads:[~2026-02-11 4:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 5:29 [PATCH net v2 0/4] bnxt_en: Fix RSS context and ntuple filter issues Michael Chan
2026-02-06 5:29 ` [PATCH net v2 1/4] bnxt_en: Fix RSS context delete logic Michael Chan
2026-02-06 5:29 ` [PATCH net v2 2/4] bnxt_en: Don't overload fw_vnic_id for RSS context's filters Michael Chan
2026-02-06 5:29 ` [PATCH net v2 3/4] bnxt_en: Fix deleting of Ntuple filters Michael Chan
2026-02-06 5:29 ` [PATCH net v2 4/4] selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up Michael Chan
2026-02-06 18:45 ` Bobby Eshleman
2026-02-08 16:26 ` Pavan Chebbi
2026-02-11 1:46 ` Jakub Kicinski
2026-02-11 3:58 ` Pavan Chebbi
2026-02-11 4:17 ` Jakub Kicinski [this message]
2026-02-11 5:15 ` Pavan Chebbi
2026-02-11 7:59 ` Pavan Chebbi
2026-02-11 16:31 ` Jakub Kicinski
2026-02-11 16:38 ` Pavan Chebbi
2026-02-11 16:58 ` Jakub Kicinski
2026-02-11 17:23 ` Pavan Chebbi
2026-02-11 17:50 ` Pavan Chebbi
2026-02-12 8:12 ` [PATCH 1/1] " Pavan Chebbi
2026-02-13 1:52 ` Jakub Kicinski
2026-02-13 3:52 ` Pavan Chebbi
2026-02-21 0:40 ` patchwork-bot+netdevbpf
2026-02-07 5:12 ` 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=20260210201706.1da13881@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew.gospodarek@broadcom.com \
--cc=bobbyeshleman@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.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.