From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: mlx5 broken affinity Date: Thu, 9 Nov 2017 18:01:04 +0200 Message-ID: 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; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , Tariq Toukan , Saeed Mahameed , Networking , Leon Romanovsky , Saeed Mahameed , Kernel Team , Christoph Hellwig To: Thomas Gleixner Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:53493 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752355AbdKIQBI (ORCPT ); Thu, 9 Nov 2017 11:01:08 -0500 Received: by mail-wm0-f67.google.com with SMTP id s66so2926328wmf.2 for ; Thu, 09 Nov 2017 08:01:07 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: > The early discussion of the managed facility came to the conclusion that it > will manage this stuff completely to allow fixed association of 'queue / > interrupt / corresponding memory' to a single CPU or a set of CPUs. That > removes a lot of 'affinity' handling magic from the driver and utilizes the > hardware in a sensible way. That was not my decision, really. It surely > made sense to me and I helped Christoph to implement it. > > The real question is whether you want to have the fixed 'queue / interrupt/ > corresponding memory association' and get rid of all the 'affinity' dance > in your driver or not. > > If you answer that question with 'yes' then the consequence is that there > is no knob. > > If you answer that question with 'no' then you should not use > the managed facility in the first place and if you need parts of that > functionality then this needs to be added to the core code _before_ a > driver gets converted and not afterwards. point taken. > It's not my problem if people decide, to use this and then trip over the > limitations after the changes hit the tree. This could have been figured > out before even a single patch was posted. That's correct, I could have known that, but I didn't, and from your reply, I understand there is really only a single way forward... > Now you try to blame the people who implemented the managed affinity stuff > for the wreckage, which was created by people who changed drivers to use > it. Nice try. I'm not trying to blame anyone, really. I was just trying to understand how to move forward with making users happy and still enjoy subsystem services instead of doing lots of similar things inside mlx5 driver.