Message ID | 20250211210657.428439-1-ahmed.zaki@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | net: napi: add CPU affinity to napi->config | expand |
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.
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.