On Thu, Jun 9, 2016 at 7:09 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Jun 08, 2016 at 03:48:10PM -0400, Ming Lin wrote: >> It adds check code to blk_mq_update_queue_map(). >> But it seems too aggresive because it's not an error that some hw queues >> were not mapped to sw queues. >> >> So this series just add a new function blk_mq_hctx_mapped() to check >> how many hw queues were mapped. And the driver(for example, nvme-rdma) >> that cares about it will do the check. > > I think it would be better to have this number available a structure > field. Any reason not to update nr_hw_queues in the tag set > with the actual number of queues? One reason is we don't know which hctx(s) not mapped. HW Queue 1 <-> CPU 0,4 HW Queue 2 <-> CPU 1,5 HW Queue 3 <-> None HW Queue 4 <-> CPU 2,6 HW Queue 5 <-> CPU 3,7 HW Queue 6 <-> None If we updated nr_hw_queues from 6 to 4, then queue_for_each_hw_ctx will not work. #define queue_for_each_hw_ctx(q, hctx, i) \ for ((i) = 0; (i) < (q)->nr_hw_queues && \ ({ hctx = (q)->queue_hw_ctx[i]; 1; }); (i)++) -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html