From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Hellwig <hch@lst.de>
Subject: Re: mlx5 broken affinity
Date: Thu, 9 Nov 2017 11:09:48 +0100
Message-ID: <20171109100948.GA18320@lst.de>
References: <3af0c164-8dde-b6f0-45e1-edbbb28e7f73@mellanox.com> <83d3944f-8a31-eb31-93db-294906630b0e@grimberg.me> <556f3ff5-c1d4-25c6-7bfc-9866c0d9b323@fb.com> <9384acdc-a5d8-872c-0034-9a3869f4fc8b@grimberg.me> <alpine.DEB.2.20.1711021907420.2824@nanos> <1d2e9304-089a-a769-9f38-a742dc066baf@grimberg.me> <alpine.DEB.2.20.1711071551330.1716@nanos> <ce53b7df-7072-0ff2-5922-8f3cb340c86a@grimberg.me> <063D6719AE5E284EB5DD2968C1650D6DD00B6353@AcuExch.aculab.com> <98ba68ee-a21c-e509-d4c3-e21c2ec138f8@kernel.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: David Laight <David.Laight@ACULAB.COM>,
        'Sagi Grimberg' <sagi@grimberg.me>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jes Sorensen <jsorensen@fb.com>,
        Tariq Toukan <tariqt@mellanox.com>,
        Saeed Mahameed <saeedm@dev.mellanox.co.il>,
        Networking <netdev@vger.kernel.org>,
        Leon Romanovsky <leonro@mellanox.com>,
        Saeed Mahameed <saeedm@mellanox.com>,
        Kernel Team <kernel-team@fb.com>,
        Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Return-path: <netdev-owner@vger.kernel.org>
Received: from verein.lst.de ([213.95.11.211]:36424 "EHLO newverein.lst.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752672AbdKIKJt (ORCPT <rfc822;netdev@vger.kernel.org>);
        Thu, 9 Nov 2017 05:09:49 -0500
Content-Disposition: inline
In-Reply-To: <98ba68ee-a21c-e509-d4c3-e21c2ec138f8@kernel.dk>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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.