netdev - Re: mlx5 broken affinity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171109100948.GA18320@lst.de>
Date:   Thu, 9 Nov 2017 11:09:48 +0100
From:   Christoph Hellwig <hch@....de>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     David Laight <David.Laight@...LAB.COM>,
        'Sagi Grimberg' <sagi@...mberg.me>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jes Sorensen <jsorensen@...com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Saeed Mahameed <saeedm@....mellanox.co.il>,
        Networking <netdev@...r.kernel.org>,
        Leon Romanovsky <leonro@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Kernel Team <kernel-team@...com>,
        Christoph Hellwig <hch@....de>
Subject: Re: mlx5 broken affinity

On Wed, Nov 08, 2017 at 09:13:59AM -0700, Jens Axboe wrote:
> There are numerous valid reasons to be able to set the affinity, for
> both nics and block drivers. It's great that the kernel has a predefined
> layout that works well, but users do need the flexibility to be able to
> reconfigure affinities, to suit their needs.

Managed interrupts are about more than just setting affinities - they
bind a a vector (which means a queue) to a specific cpu or set of cpus.
This is extremely useful to deal with hotplug issues and also makes
life a lot easier in general.

> But that particular case is completely orthogonal to whether or not we
> should allow the user to reconfigure. The answer to that is clearly YES,
> and we should ensure that this is possible.

And why is the answer yes?  If the anser is YES it means we need explicit
boilerplate code to deal with  cpu hotplug in every driver not using
managed interrupts (even if optionally), so it is a non-trivial tradeoff.