From: Jakub Kicinski <kuba@kernel.org>
To: Joe Damato <jdamato@fastly.com>
Cc: netdev@vger.kernel.org, ahmed.zaki@intel.com,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] documentation: networking: Add NAPI config
Date: Mon, 10 Feb 2025 19:20:58 -0800 [thread overview]
Message-ID: <20250210192058.26b59185@kernel.org> (raw)
In-Reply-To: <Z6q7B79h73ydzOhM@LQ3V64L9R2>
On Mon, 10 Feb 2025 18:50:47 -0800 Joe Damato wrote:
> On Mon, Feb 10, 2025 at 06:16:35PM -0800, Jakub Kicinski wrote:
> > On Sat, 8 Feb 2025 01:28:21 +0000 Joe Damato wrote:
> > > +Persistent NAPI config
> > > +----------------------
> > > +
> > > +Drivers can opt-in to using a persistent NAPI configuration space by calling
> >
> > Should we be more forceful? I think for new drivers the _add_config()
> > API should always be preferred given the benefits.
>
> How about: "Drivers should opt-in ..." instead? I have no strong
> preference.
A bit more editing may be beneficial, lead with the problem:
Drivers often allocate and free NAPI instances dynamically. This leads
to loss of NAPI-related user configuration, each time NAPI instances
are reallocated. The netif_napi_add_config() API prevents this loss of
configuration by associating each NAPI instance with...
Drivers should try to use netif_napi_add_config() whenever possible.
prev parent reply other threads:[~2025-02-11 3:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 1:28 [PATCH net-next] documentation: networking: Add NAPI config Joe Damato
2025-02-08 3:58 ` Bagas Sanjaya
2025-02-11 2:16 ` Jakub Kicinski
2025-02-11 2:38 ` Randy Dunlap
2025-02-11 2:50 ` Joe Damato
2025-02-11 3:20 ` Jakub Kicinski [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=20250210192058.26b59185@kernel.org \
--to=kuba@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jdamato@fastly.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.