From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [RFD] Managed interrupt affinities [ Was: mlx5 broken affinity ] Date: Mon, 13 Nov 2017 23:49:51 +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> <7f7aab77-b0b6-f8fa-0b57-3e3c1755eeaa@fb.com> <4888ac89-22d5-0700-daa1-d604e4c54970@fb.com> <4bae1d1d-d401-115d-91cc-4b7df88b02c5@grimberg.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jens Axboe , Jes Sorensen , Tariq Toukan , Saeed Mahameed , Networking , Leon Romanovsky , Saeed Mahameed , Kernel Team , Christoph Hellwig To: Thomas Gleixner Return-path: Received: from mail-wm0-f45.google.com ([74.125.82.45]:37828 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751391AbdKMVtz (ORCPT ); Mon, 13 Nov 2017 16:49:55 -0500 Received: by mail-wm0-f45.google.com with SMTP id v186so9143825wma.2 for ; Mon, 13 Nov 2017 13:49:54 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: >> Can you explain what do you mean by "subsystem"? I thought that the >> subsystem would be the irq subsystem (which means you are the one to provide >> the needed input :) ) and the driver would pass in something >> like msi_irq_ops to pci_alloc_irq_vectors() if it supports the driver >> requirements that you listed and NULL to tell the core to leave it alone >> and do what it sees fit (or pass msi_irq_ops with flag that means that). >> >> ops structure is a very common way for drivers to communicate with a >> subsystem core. > > So if you look at the above pseudo code then the subsys_*_move_callbacks > are probably subsystem specific, i.e. block or networking. > > Those subsystem callbacks might either handle it at the subsystem level > directly or call into the particular driver. Personally I do not think that integrating this to networking/block stacks in that level is going to work. drivers don't communicate any information on what they do with msi(x) vectors (and I'm not sure they should). I think that driver that uses managed facilities is up to its own discretion, it interacts with the irq subsystem to allocate the vectors so it make sense to me that it should pass in the ops directly and handle the callouts. > That's certainly out of the scope what the generic interrupt code can do :) Don't get me wrong, I'm all for adding useful helpers in net/ and block/ if drivers need some services from the core subsystem or if drivers end up sharing lots of logic. For example, drivers already take care of draining queues when device hot unplug is triggered, so they must be able to get it right for IRQ vector migration (at least I assume).