Re: [PATCH net-next 4/8] net/mlx5e: Consider IRQ affinity changes in NAPI poll

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:davem@davemloft.net]
Sent: Monday, November 02, 2015 12:34 AM
To: Or Gerlitz <redacted>
Cc: netdev@vger.kernel.org; Saeed Mahameed <redacted>; Achiad Shochat <redacted>
Subject: Re: [PATCH net-next 4/8] net/mlx5e: Consider IRQ affinity changes in NAPI poll

From: Or Gerlitz <redacted>
Date: Sun,  1 Nov 2015 19:35:18 +0200

quoted

@@ -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.