On Tue, Aug 13, 2024 at 05:17:10PM -0700, Jakub Kicinski wrote: > On Mon, 12 Aug 2024 14:56:21 +0000 Joe Damato wrote: > > Several drivers make a check in their napi poll functions to determine > > if the CPU affinity of the IRQ has changed. If it has, the napi poll > > function returns a value less than the budget to force polling mode to > > be disabled, so that it can be rescheduled on the correct CPU next time > > the softirq is raised. > > Any reason not to use the irq number already stored in napi_struct ? Thanks for taking a look. IIUC, that's possible if i40e, iavf, and gve are updated to call netif_napi_set_irq first, which I could certainly do. But as Stanislav points out, I would be adding a call to irq_get_effective_affinity_mask in the hot path where one did not exist before for 4 of 5 drivers. In that case, it might make more sense to introduce: bool napi_affinity_no_change(const struct cpumask *aff_mask) instead and the drivers which have a cached mask can pass it in and gve can be updated later to cache it. Not sure how crucial avoiding the irq_get_effective_affinity_mask call is; I would guess maybe some driver owners would object to adding a new call in the hot path where one didn't exist before. What do you think?
