Hi Dave, We agree with you, we will drop this patch for now and will think of a cleaner approach to fix this in the future.
> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, November 02, 2015 12:34 AM > To: Or Gerlitz <ogerl...@mellanox.com> > Cc: netdev@vger.kernel.org; Saeed Mahameed <sae...@mellanox.com>; Achiad > Shochat <ach...@mellanox.com> > Subject: Re: [PATCH net-next 4/8] net/mlx5e: Consider IRQ affinity changes in > NAPI poll > > From: Or Gerlitz <ogerl...@mellanox.com> > Date: Sun, 1 Nov 2015 19:35:18 +0200 > >> @@ -49,6 +50,15 @@ struct mlx5_cqe64 *mlx5e_get_cqe(struct mlx5e_cq *cq) >> return cqe; >> } >> >> +static inline bool mlx5e_no_channel_affinity_change(struct >> +mlx5e_channel *c) { >> + int current_cpu = smp_processor_id(); >> + struct irq_data *d = irq_desc_get_irq_data(c->irq_desc); >> + struct cpumask *aff = irq_data_get_affinity_mask(d); >> + >> + return cpumask_test_cpu(current_cpu, aff); } > > This is so much pointer dereferencing and then a bitmask test as well. > > Are you really sure sure an extremely rare situation warrants this test every > single NAPI poll call? > > If this is a real problem, then every driver is susceptible to the issue and > it therefore warrants a generic solution. And if we have generic > infrastructure for this situation in the code NAPI polling networking code, I > guarantee that it will probably be implemented much more cheaply than this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
