From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: mlx5 broken affinity Date: Thu, 9 Nov 2017 08:19:37 -0700 Message-ID: <6ee51a50-81a6-61d6-2e08-f9d4ffb3aacf@fb.com> References: <2187e555-2c4e-ef55-1c3a-17f5af54d762@fb.com> <573060a9-19a7-9133-ef52-fa947088dabb@fb.com> <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> <1d2e9304-089a-a769-9f38-a742dc066baf@grimberg.me> <67a1157e-06e7-479c-993e-bdf42fd613c6@fb.com> <69a46009-184f-d925-289c-6036f0bf2554@grimberg.me> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: Tariq Toukan , Saeed Mahameed , Networking , Leon Romanovsky , Saeed Mahameed , Kernel Team , Christoph Hellwig To: Sagi Grimberg , Thomas Gleixner , Jes Sorensen Return-path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:37194 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806AbdKIPUV (ORCPT ); Thu, 9 Nov 2017 10:20:21 -0500 In-Reply-To: <69a46009-184f-d925-289c-6036f0bf2554@grimberg.me> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 11/09/2017 03:50 AM, Sagi Grimberg wrote: > Thomas, > >>> Because the user sometimes knows better based on statically assigned >>> loads, or the user wants consistency across kernels. It's great that the >>> system is better at allocating this now, but we also need to allow for a >>> user to change it. Like anything on Linux, a user wanting to blow off >>> his/her own foot, should be allowed to do so. >> >> That's fine, but that's not what the managed affinity facility provides. If >> you want to leverage the spread mechanism, but avoid the managed part, then >> this is a different story and we need to figure out how to provide that >> without breaking the managed side of it. >> >> As I said it's possible, but I vehemently disagree, that this is a bug in >> the core code, as it was claimed several times in this thread. >> >> The real issue is that the driver was converted to something which was >> expected to behave differently. That's hardly a bug in the core code, at >> most it's a documentation problem. > > I disagree here, this is not a device specific discussion. The question > of exposing IRQ affinity assignment knob to user-space holds for every > device (NICs, HBAs and alike). The same issue could have been raised on > any other device using managed affinitization (and we have quite a few > of those now). I can't see any reason why its OK for device X to use it > while its not OK for device Y to use it. > > If the resolution is "YES we must expose a knob to user-space" then the > managed facility is unusable in its current form for *any* device. If > the answer is "NO, user-space can't handle all the stuff the kernel can" > then we should document it. This is really device independent. Completely agree, and honestly I'm pretty baffled we're even having to argue this point. -- Jens Axboe