From: Stanislav Fomichev <stfomichev@gmail•com>
To: Joe Damato <jdamato@fastly•com>
Cc: netdev@vger•kernel.org, mkarsten@uwaterloo•ca,
skhawaja@google•com, sdf@fomichev•me, bjorn@rivosinc•com,
amritha.nambiar@intel•com, sridhar.samudrala@intel•com,
willemdebruijn.kernel@gmail•com,
Alexander Lobakin <aleksander.lobakin@intel•com>,
Breno Leitao <leitao@debian•org>,
Daniel Jurgens <danielj@nvidia•com>,
David Ahern <dsahern@kernel•org>,
"David S. Miller" <davem@davemloft•net>,
Donald Hunter <donald.hunter@gmail•com>,
Eric Dumazet <edumazet@google•com>,
"moderated list:INTEL ETHERNET DRIVERS"
<intel-wired-lan@lists•osuosl.org>,
Jakub Kicinski <kuba@kernel•org>,
Jesper Dangaard Brouer <hawk@kernel•org>,
Jiri Pirko <jiri@resnulli•us>,
Johannes Berg <johannes.berg@intel•com>,
Jonathan Corbet <corbet@lwn•net>,
Kory Maincent <kory.maincent@bootlin•com>,
Leon Romanovsky <leon@kernel•org>,
"open list:DOCUMENTATION" <linux-doc@vger•kernel.org>,
open list <linux-kernel@vger•kernel.org>,
"open list:MELLANOX MLX4 core VPI driver"
<linux-rdma@vger•kernel.org>,
Lorenzo Bianconi <lorenzo@kernel•org>,
Michael Chan <michael.chan@broadcom•com>,
Mina Almasry <almasrymina@google•com>,
Paolo Abeni <pabeni@redhat•com>,
Przemek Kitszel <przemyslaw.kitszel@intel•com>,
Saeed Mahameed <saeedm@nvidia•com>,
Sebastian Andrzej Siewior <bigeasy@linutronix•de>,
Tariq Toukan <tariqt@nvidia•com>,
Tony Nguyen <anthony.l.nguyen@intel•com>,
Xuan Zhuo <xuanzhuo@linux•alibaba.com>
Subject: Re: [RFC net-next v4 0/9] Add support for per-NAPI config via netlink
Date: Thu, 3 Oct 2024 16:29:37 -0700 [thread overview]
Message-ID: <Zv8o4eliTO60odQe@mini-arch> (raw)
In-Reply-To: <20241001235302.57609-1-jdamato@fastly.com>
On 10/01, Joe Damato wrote:
> Greetings:
>
> Welcome to RFC v4.
>
> Very important and significant changes have been made since RFC v3 [1],
> please see the changelog below for details.
>
> A couple important call outs for this revision for reviewers:
>
> 1. idpf embeds a napi_struct in an internal data structure and
> includes an assertion on the size of napi_struct. The maintainers
> have stated that they think anyone touching napi_struct should update
> the assertion [2], so I've done this in patch 3.
>
> Even though the assertion has been updated, I've given the
> cacheline placement of napi_struct within idpf's internals no
> thought or consideration.
>
> Would appreciate other opinions on this; I think idpf should be
> fixed. It seems unreasonable to me that anyone changing the size of
> a struct in the core should need to think about cachelines in idpf.
[..]
> 2. This revision seems to work (see below for a full walk through). Is
> this the behavior we want? Am I missing some use case or some
> behavioral thing other folks need?
The walk through looks good!
> 3. Re a previous point made by Stanislav regarding "taking over a NAPI
> ID" when the channel count changes: mlx5 seems to call napi_disable
> followed by netif_napi_del for the old queues and then calls
> napi_enable for the new ones. In this RFC, the NAPI ID generation
> is deferred to napi_enable. This means we won't end up with two of
> the same NAPI IDs added to the hash at the same time (I am pretty
> sure).
[..]
> Can we assume all drivers will napi_disable the old queues before
> napi_enable the new ones? If yes, we might not need to worry about
> a NAPI ID takeover function.
With the explicit driver opt-in via netif_napi_add_config, this
shouldn't matter? When somebody gets to converting the drivers that
don't follow this common pattern they'll have to solve the takeover
part :-)
next prev parent reply other threads:[~2024-10-03 23:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 23:52 [RFC net-next v4 0/9] Add support for per-NAPI config via netlink Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 1/9] net: napi: Make napi_defer_hard_irqs per-NAPI Joe Damato
2024-10-08 22:08 ` Jakub Kicinski
2024-10-01 23:52 ` [RFC net-next v4 2/9] netdev-genl: Dump napi_defer_hard_irqs Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 3/9] net: napi: Make gro_flush_timeout per-NAPI Joe Damato
2024-10-08 18:22 ` Joe Damato
2024-10-08 22:10 ` Jakub Kicinski
2024-10-01 23:52 ` [RFC net-next v4 4/9] netdev-genl: Dump gro_flush_timeout Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 5/9] net: napi: Add napi_config Joe Damato
2024-10-08 18:19 ` Joe Damato
2024-10-08 22:17 ` Jakub Kicinski
2024-10-08 22:28 ` Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 6/9] netdev-genl: Support setting per-NAPI config values Joe Damato
2024-10-08 18:20 ` Joe Damato
2024-10-08 22:19 ` Jakub Kicinski
2024-10-08 23:00 ` Joe Damato
2024-10-08 23:19 ` Jakub Kicinski
2024-10-08 23:57 ` Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 7/9] bnxt: Add support for persistent NAPI config Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 8/9] mlx5: " Joe Damato
2024-10-01 23:52 ` [RFC net-next v4 9/9] mlx4: Add support for persistent NAPI config to RX CQs Joe Damato
2024-10-03 23:29 ` Stanislav Fomichev [this message]
2024-10-03 23:53 ` [RFC net-next v4 0/9] Add support for per-NAPI config via netlink Joe Damato
2024-10-04 2:33 ` Joe Damato
2024-10-04 16:22 ` Stanislav Fomichev
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=Zv8o4eliTO60odQe@mini-arch \
--to=stfomichev@gmail$(echo .)com \
--cc=aleksander.lobakin@intel$(echo .)com \
--cc=almasrymina@google$(echo .)com \
--cc=amritha.nambiar@intel$(echo .)com \
--cc=anthony.l.nguyen@intel$(echo .)com \
--cc=bigeasy@linutronix$(echo .)de \
--cc=bjorn@rivosinc$(echo .)com \
--cc=corbet@lwn$(echo .)net \
--cc=danielj@nvidia$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=donald.hunter@gmail$(echo .)com \
--cc=dsahern@kernel$(echo .)org \
--cc=edumazet@google$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=intel-wired-lan@lists$(echo .)osuosl.org \
--cc=jdamato@fastly$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=johannes.berg@intel$(echo .)com \
--cc=kory.maincent@bootlin$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=leitao@debian$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=linux-doc@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-rdma@vger$(echo .)kernel.org \
--cc=lorenzo@kernel$(echo .)org \
--cc=michael.chan@broadcom$(echo .)com \
--cc=mkarsten@uwaterloo$(echo .)ca \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=przemyslaw.kitszel@intel$(echo .)com \
--cc=saeedm@nvidia$(echo .)com \
--cc=sdf@fomichev$(echo .)me \
--cc=skhawaja@google$(echo .)com \
--cc=sridhar.samudrala@intel$(echo .)com \
--cc=tariqt@nvidia$(echo .)com \
--cc=willemdebruijn.kernel@gmail$(echo .)com \
--cc=xuanzhuo@linux$(echo .)alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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