From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Paolo Abeni <pabeni@redhat.com>, netdev-bot+sashiko@kernel.org
Cc: andrew+netdev@lunn.ch, kuba@kernel.org, davem@davemloft.net,
edumazet@google.com, horms@kernel.org, linux@armlinux.org.uk,
kuniyu@google.com, sdf.kernel@gmail.com,
thomas.petazzoni@bootlin.com, alexis.lothore@bootlin.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: Don't allow disabling napi kthread mode while napi instances are disabled
Date: Tue, 13 Oct 2026 09:48:41 +0200 [thread overview]
Message-ID: <670f3506-efe4-4d73-a71d-7140547f1cfe@bootlin.com> (raw)
In-Reply-To: <24dbe3af-8706-4369-8308-d3ad558fea71@redhat.com>
Hi Paolo,
On 10/12/26 18:31, Paolo Abeni wrote:
> On 10/8/26 12:19, Maxime Chevallier wrote:
>> On 10/8/26 04:11, netdev-bot+sashiko@kernel.org wrote:
>>> Would it be better to handle disabled NAPIs in the stop path itself,
>>> napi_stop_kthread() or napi_set_threaded(), rather than only guarding the
>>> explicit disable branch?
>>
>> Hmmm maybe yes
> My personal take is that the complexity of addressing the issue for good at
> the core level sounds like a good argument to fix this at the device level,
> one device at the time, as needed.
Fixing that in drivers isn't enough however. The visible problem of hanging while
disabling threaded mode if the interface is down would be addressed, but not the
corner cases such as "disabling threaded mode while changing the MTU" for example.
And this is a lot harder to test :(
>
> Otherwise I'll probably got for the suggested path above.
My brain is becoming a bit more operational now that the conference flu I caught
last week is healing, I'll spin another round see if I can get that addressed.
Maxime
prev parent reply other threads:[~2026-10-13 7:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 14:11 [PATCH net v2] net: Don't allow disabling napi kthread mode while napi instances are disabled Maxime Chevallier
2026-10-08 2:11 ` netdev-bot+sashiko
2026-10-08 10:19 ` Maxime Chevallier
2026-10-12 16:31 ` Paolo Abeni
2026-10-13 7:48 ` Maxime Chevallier [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=670f3506-efe4-4d73-a71d-7140547f1cfe@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexis.lothore@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf.kernel@gmail.com \
--cc=thomas.petazzoni@bootlin.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