From: Jakub Kicinski <kuba@kernel.org>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Joe Damato <jdamato@fastly.com>,
"David S . Miller " <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
almasrymina@google.com, willemb@google.com,
mkarsten@uwaterloo.ca, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v4 1/4] Add support to set napi threaded for individual napi
Date: Tue, 25 Mar 2025 07:51:00 -0700 [thread overview]
Message-ID: <20250325075100.77b5c4c0@kernel.org> (raw)
In-Reply-To: <Z92dcVfEiI2g8XOZ@LQ3V64L9R2>
On Fri, 21 Mar 2025 10:10:09 -0700 Joe Damato wrote:
> > +int napi_set_threaded(struct napi_struct *napi, bool threaded)
> > +{
> > + if (napi->dev->threaded)
> > + return -EINVAL;
>
> This works differently than the existing per-NAPI defer_hard_irqs /
> gro_flush_timeout which are also interface wide.
>
> In that implementation:
> - the per-NAPI value is set when requested by the user
> - when the sysfs value is written, all NAPIs have their values
> overwritten to the sysfs value
>
> I think either:
> - This implementation should work like the existing ones, or
> - The existing ones should be changed to work like this
>
> I am opposed to have two different behaviors when setting per-NAPI
> vs system/nic-wide sysfs values.
>
> I don't have a preference on which behavior is chosen, but the
> behavior should be the same for all of the things that are
> system/nic-wide and moving to per-NAPI.
And we should probably have a test that verifies the consistency
for all the relevant attrs.
next prev parent reply other threads:[~2025-03-25 14:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 2:15 [PATCH net-next v4 0/4] Add support to do threaded napi busy poll Samiullah Khawaja
2025-03-21 2:15 ` [PATCH net-next v4 1/4] Add support to set napi threaded for individual napi Samiullah Khawaja
2025-03-21 17:10 ` Joe Damato
2025-03-25 14:51 ` Jakub Kicinski [this message]
2025-04-01 18:27 ` Jakub Kicinski
2025-04-14 17:16 ` Samiullah Khawaja
2025-03-25 14:52 ` Jakub Kicinski
2025-03-21 2:15 ` [PATCH net-next v4 2/4] net: Create separate gro_flush helper function Samiullah Khawaja
2025-03-21 17:16 ` Joe Damato
2025-03-27 16:42 ` Samiullah Khawaja
2025-03-21 2:15 ` [PATCH net-next v4 3/4] Extend napi threaded polling to allow kthread based busy polling Samiullah Khawaja
2025-03-21 17:39 ` Joe Damato
2025-03-27 16:39 ` Samiullah Khawaja
2025-03-21 2:15 ` [PATCH net-next v4 4/4] selftests: Add napi threaded busy poll test in `busy_poller` Samiullah Khawaja
2025-03-24 2:38 ` [PATCH net-next v4 0/4] Add support to do threaded napi busy poll Martin Karsten
2025-03-25 16:40 ` Samiullah Khawaja
2025-03-25 17:47 ` Martin Karsten
2025-03-26 20:34 ` Samiullah Khawaja
2025-03-26 21:22 ` Martin Karsten
2025-03-26 21:57 ` Stanislav Fomichev
2025-03-27 18:40 ` Joe Damato
2025-03-27 19:35 ` Samiullah Khawaja
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=20250325075100.77b5c4c0@kernel.org \
--to=kuba@kernel.org \
--cc=almasrymina@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jdamato@fastly.com \
--cc=mkarsten@uwaterloo.ca \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=skhawaja@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;
as well as URLs for NNTP newsgroup(s).