From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: mlx5 broken affinity Date: Thu, 9 Nov 2017 12:50:31 +0200 Message-ID: <69a46009-184f-d925-289c-6036f0bf2554@grimberg.me> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tariq Toukan , Saeed Mahameed , Networking , Leon Romanovsky , Saeed Mahameed , Kernel Team , Christoph Hellwig To: Thomas Gleixner , Jes Sorensen Return-path: Received: from mail-wr0-f196.google.com ([209.85.128.196]:47431 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752242AbdKIKuf (ORCPT ); Thu, 9 Nov 2017 05:50:35 -0500 Received: by mail-wr0-f196.google.com with SMTP id k61so5175227wrc.4 for ; Thu, 09 Nov 2017 02:50:35 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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.