[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80c80ec9-2c77-7c1b-ab41-b67c422b3e66@fb.com>
Date: Thu, 2 Nov 2017 13:13:42 -0400
From: Jes Sorensen <jsorensen@...com>
To: Sagi Grimberg <sagi@...mberg.me>,
Tariq Toukan <tariqt@...lanox.com>,
Saeed Mahameed <saeedm@....mellanox.co.il>
CC: Networking <netdev@...r.kernel.org>,
Leon Romanovsky <leonro@...lanox.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Kernel Team <kernel-team@...com>,
Christoph Hellwig <hch@....de>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: mlx5 broken affinity
On 11/02/2017 12:14 PM, Sagi Grimberg wrote:
>
>> This wasn't to start a debate about which allocation method is the
>> perfect solution. I am perfectly happy with the new default, the part
>> that is broken is to take away the user's option to reassign the
>> affinity. That is a bug and it needs to be fixed!
>
> Well,
>
> I would really want to wait for Thomas/Christoph to reply, but this
> simple change fixed it for me:
> --
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 573dc52b0806..eccd06be5e44 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -146,8 +146,7 @@ bool irq_can_set_affinity_usr(unsigned int irq)
> {
> struct irq_desc *desc = irq_to_desc(irq);
>
> - return __irq_can_set_affinity(desc) &&
> - !irqd_affinity_is_managed(&desc->irq_data);
> + return __irq_can_set_affinity(desc);
> }
The part I don't get here is why the mlx5 driver change was allowed to
set the irqs to 'managed'? One thing is to use the generic system for
initial allocation, which is all great, but the change shouldn't mark
the irq affinity mapping as managed.
Jes
Powered by blists - more mailing lists