netdev - Re: [RFD] Managed interrupt affinities [ Was: mlx5 broken affinity ]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ab819459-0e5b-e50b-a0b2-cc46fbc42674@grimberg.me>
Date:   Mon, 13 Nov 2017 23:49:51 +0200
From:   Sagi Grimberg <sagi@...mberg.me>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Jens Axboe <axboe@...com>, Jes Sorensen <jsorensen@...com>,
        Tariq Toukan <tariqt@...lanox.com>,
        Saeed Mahameed <saeedm@....mellanox.co.il>,
        Networking <netdev@...r.kernel.org>,
        Leon Romanovsky <leonro@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Kernel Team <kernel-team@...com>,
        Christoph Hellwig <hch@....de>
Subject: Re: [RFD] Managed interrupt affinities [ Was: mlx5 broken affinity ]

>> 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).