All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Sebastian Gottschall' <s.gottschall@dd-wrt.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Felix Fietkau <nbd@nbd.name>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Hillf Danton <hdanton@sina.com>
Subject: RE: [PATCH] net: add support for threaded NAPI polling
Date: Thu, 30 Jul 2020 15:42:49 +0000	[thread overview]
Message-ID: <1743bcaa2dfb4b6393b4d228cf079fe3@AcuMS.aculab.com> (raw)
In-Reply-To: <5aa0c26f-d3f1-b33f-a598-e4727d6f10f0@dd-wrt.com>

From: Sebastian Gottschall
> Sent: 30 July 2020 15:30
...
> > Quite frankly, I do believe this STATE_THREADED status should be a generic NAPI attribute
> > that can be changed dynamically, at admin request, instead of having to change/recompile
> > a driver.

> thats not that easy. wifi devices do use dummy netdev devices. they are
> not visible to sysfs and other administrative options.
> so changing it would just be possible if a special mac80211 based
> control would be implemented for these drivers.
> for standard netdev devices it isnt a big thing to implement a
> administrative control by sysfs (if you are talking about such a feature)

ISTM that a global flag that made all NAPI callbacks be made
from a worker thread rather than softint would be more approriate.
Or even something that made the softint callbacks themselves
only run an a specific high(ish) priority kernel thread.

While it might slow down setups that need very low ethernet
latency it will help those that don't want application RT threads
to be 'stolen' by the softint code while they hold application
mutex or are waiting to be woken by a cv.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2020-07-30 15:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 16:50 [PATCH] net: add support for threaded NAPI polling Felix Fietkau
2020-07-29 17:44 ` Eric Dumazet
2020-07-30 14:30   ` Sebastian Gottschall
2020-07-30 15:42     ` David Laight [this message]
2020-07-30 17:19       ` Sebastian Gottschall
2020-07-30 16:08     ` Eric Dumazet
2020-07-30 17:21       ` Sebastian Gottschall
2020-07-31 16:36         ` Eric Dumazet
2020-08-02 14:27           ` Sebastian Gottschall
2020-08-04 20:41             ` Eric Dumazet

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=1743bcaa2dfb4b6393b4d228cf079fe3@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hdanton@sina.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=s.gottschall@dd-wrt.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.