On 10/29/18 2:25 PM, Bart Van Assche wrote: > On Mon, 2018-10-29 at 14:09 -0600, Jens Axboe wrote: >> hctx->type will be set to the value of the first type. This is all driver >> private, blk-mq could not care less what the value of the type means. >> >> As to the other question, it works just fine since that is the queue >> that is being accessed. There's no confusion there. I think you're >> misunderstanding how it's seutp. To use nvme as the example, type 0 >> would be reads, 1 writes, and 2 pollable queues. If reads and writes >> share the same set of hardware queues, then type 1 simply doesn't >> exist in terms of ->flags_to_type() return value. This is purely >> driven by the driver. That hook is the only decider of where something >> will go. If we share hctx sets, we share the same hardware queue as >> well. There is just the one set for that case. > > How about adding a comment in blk-mq.h that explains that hardware queues can > be shared among different hardware queue types? I think this is nontrivial and > deserves a comment. Sure, I can do that. I guess a key concept that is confusing based on your above question is that the sets don't have to be consecutive. It's perfectly valid to have 0 and 2 be the available queues, and nothing for 1. For example. BTW, split up the incremental patch, find them here: http://git.kernel.dk/cgit/linux-block/commit/?h=mq-maps&id=6890d88deecfd3723ce620d82f5fc80485f9caec and http://git.kernel.dk/cgit/linux-block/commit/?h=mq-maps&id=907725dff2f8cc6d1502a9123f930b8d3708bd02 -- Jens Axboe
