From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751402AbbI2Wpx (ORCPT ); Tue, 29 Sep 2015 18:45:53 -0400 Received: from mga01.intel.com ([192.55.52.88]:42950 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810AbbI2Wps (ORCPT ); Tue, 29 Sep 2015 18:45:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,609,1437462000"; d="scan'208";a="570853956" Date: Tue, 29 Sep 2015 22:45:47 +0000 (UTC) From: Keith Busch X-X-Sender: vmware@localhost.lm.intel.com To: Ming Lei cc: Jens Axboe , Keith Busch , Linux Kernel Mailing List , Matthew Wilcox , linux-nvme , Christoph Hellwig Subject: Re: [PATCH 0/3] blk-mq & nvme: introduce .map_changed In-Reply-To: Message-ID: References: <1443496857-26887-1-git-send-email-tom.leiming@gmail.com> <560AA46A.9060205@kernel.dk> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2015, Ming Lei wrote: > Yes, I thought of that before, but it has the following cons: > > - some drivers/devices may need different IRQ affinity policy, such as virtio > devices which has its own set affinity handler(see virtqueue_set_affinity()), That's not a very good example to support your cause; virtio_scsi's use is a perfect example for one that would benefit from letting blk-mq handle affinity. virtio_scsi sets affinity only when there is a 1:1 mapping of cpu's to queue's, but this driver doesn't know the mapping that blk-mq used, creating a potentially less than optimal mapping. > - block core has to get the irq vector information which has to be > setup/finalized > before blk-mq uses that for setting irq affinity, for example, in case > NVMe's admin > queue, its vector can be changed after admin queue's initialization. Why do you want to put a hint on the admin queue's irq?