[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250215094338.7863bcef@kernel.org>
Date: Sat, 15 Feb 2025 09:43:38 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Ahmed Zaki <ahmed.zaki@...el.com>
Cc: netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
andrew+netdev@...n.ch, edumazet@...gle.com, horms@...nel.org,
pabeni@...hat.com, davem@...emloft.net, michael.chan@...adcom.com,
tariqt@...dia.com, anthony.l.nguyen@...el.com,
przemyslaw.kitszel@...el.com, jdamato@...tly.com, shayd@...dia.com,
akpm@...ux-foundation.org, shayagr@...zon.com,
kalesh-anakkur.purayil@...adcom.com, pavan.chebbi@...adcom.com
Subject: Re: [PATCH net-next v8 0/6] net: napi: add CPU affinity to
napi->config
On Sat, 15 Feb 2025 09:41:54 -0800 Jakub Kicinski wrote:
> On Tue, 11 Feb 2025 14:06:51 -0700 Ahmed Zaki wrote:
> > Drivers usually need to re-apply the user-set IRQ affinity to their IRQs
> > after reset. However, since there can be only one IRQ affinity notifier
> > for each IRQ, registering IRQ notifiers conflicts with the ARFS rmap
> > management in the core (which also registers separate IRQ affinity
> > notifiers).
>
> Could you extract all the core changes as a first patch of the series
> (rmap and affinity together). And then have the driver conversion
> patches follow? Obviously don't do it if it'd introduce transient
> breakage. But I don't think it should, since core changes should
> be a noop before any driver opts in.
>
> The way it's split now makes the logic quite hard to review.
Ah, and please add the patch with the ksft test I shared earlier to
your series:
https://github.com/kuba-moo/linux/commit/de7d2475750ac05b6e414d7e5201e354b05cf146
it just needs a commit message, I think. The prereq patches are
in the tree now.
Powered by blists - more mailing lists