netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Yannick Vignon <yannick.vignon@oss.nxp.com>,
	Eric Dumazet <edumazet@google.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"David S. Miller" <davem@davemloft.net>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Antoine Tenart <atenart@kernel.org>,
	Alexander Lobakin <alexandr.lobakin@intel.com>,
	Paolo Abeni <pabeni@redhat.com>, Wei Wang <weiwan@google.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Yunsheng Lin <linyunsheng@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>, netdev <netdev@vger.kernel.org>,
	Vladimir Oltean <olteanv@gmail.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	mingkai.hu@nxp.com, Joakim Zhang <qiangqing.zhang@nxp.com>,
	sebastien.laveze@nxp.com, Yannick Vignon <yannick.vignon@nxp.com>
Subject: Re: [PATCH net-next 1/2] net: napi: wake up ksoftirqd if needed after scheduling NAPI
Date: Fri, 4 Feb 2022 19:03:31 +0100	[thread overview]
Message-ID: <Yf1qc7R5rFoALsCo@linutronix.de> (raw)
In-Reply-To: <20220204094522.4a233a2b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On 2022-02-04 09:45:22 [-0800], Jakub Kicinski wrote:
> Coincidentally, I believe the threaded NAPI wake up is buggy - 
> we assume the thread is only woken up when NAPI gets scheduled,
> but IIUC signal delivery and other rare paths may wake up kthreads,
> randomly.

I had to look into NAPI-threads for some reason.
What I dislike is that after enabling it via sysfs I have to:
- adjust task priority manual so it is preferred over other threads.
  This is usually important on RT. But then there is no overload
  protection.

- set an affinity-mask for the thread so it does not migrate from one
  CPU to the other. This is worse for a RT task where the scheduler
  tries to keep the task running.

Wouldn't it work to utilize the threaded-IRQ API and use that instead
the custom thread? Basically the primary handler would what it already
does (disable the interrupt) and the threaded handler would feed packets
into the stack. In the overload case one would need to lower the
thread-priority.

Sebastian

  reply	other threads:[~2022-02-04 18:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 18:40 [PATCH net-next 1/2] net: napi: wake up ksoftirqd if needed after scheduling NAPI Yannick Vignon
2022-02-03 18:40 ` [PATCH net-next 2/2] net: stmmac: move to threaded IRQ Yannick Vignon
2022-02-03 19:08 ` [PATCH net-next 1/2] net: napi: wake up ksoftirqd if needed after scheduling NAPI Eric Dumazet
2022-02-03 23:40   ` Yannick Vignon
2022-02-03 23:57     ` Eric Dumazet
2022-02-04  1:09     ` Jakub Kicinski
2022-02-04  8:19       ` Sebastian Andrzej Siewior
2022-02-04 15:43         ` Jakub Kicinski
2022-02-04 17:15           ` Yannick Vignon
2022-02-04 17:36             ` Jakub Kicinski
2022-02-04 17:45             ` Jakub Kicinski
2022-02-04 18:03               ` Sebastian Andrzej Siewior [this message]
2022-02-04 18:50                 ` Jakub Kicinski
2022-02-04 18:52                   ` Jakub Kicinski
2022-02-08 11:51                   ` Sebastian Andrzej Siewior
2022-02-08 15:35                     ` Jakub Kicinski
2022-02-08 17:45                       ` Sebastian Andrzej Siewior
2022-02-09  0:16                         ` Jakub Kicinski
2022-02-08 15:57                     ` Paolo Abeni
2022-02-08 18:21                       ` Sebastian Andrzej Siewior
2022-02-09 11:26                   ` Marc Kleine-Budde
2022-02-03 19:41 ` Sebastian Andrzej Siewior

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=Yf1qc7R5rFoALsCo@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=alexandr.lobakin@intel.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=arnd@arndb.de \
    --cc=atenart@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=kuba@kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=memxor@gmail.com \
    --cc=mingkai.hu@nxp.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=peppe.cavallaro@st.com \
    --cc=qiangqing.zhang@nxp.com \
    --cc=sebastien.laveze@nxp.com \
    --cc=weiwan@google.com \
    --cc=xiaoliang.yang_1@nxp.com \
    --cc=yannick.vignon@nxp.com \
    --cc=yannick.vignon@oss.nxp.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;
as well as URLs for NNTP newsgroup(s).