On 2014-09-22 10:31, Jens Axboe wrote:
On 2014-09-22 10:25, Bart Van Assche wrote:
On 22/09/2014 8:37, Christoph Hellwig wrote:
One thing that is missing is generation multiqueue-aware tags at the
blk-mq level, which should be as simple as always adding a queue
prefix in the tag allocation code.
Hello Christoph,
Adding a queue prefix in the tag allocation code is an interesting idea.
Encoding the hardware context index in the upper bits of the 'tag' field
in 'struct request' is something I have considered. The reason I have
not done that is because I think several block drivers assume that the
rq->tag field is a number in the range [0..queue_depth-1]. Here is just
one example from the mtip32xx driver:
fis->sect_count = ((rq->tag << 3) | (rq->tag >> 5));
Most drivers assume that the tag is within a certain range, the queue
prefix would only work on drivers where the tag number is just some
arbitrary "cookie". So for SCSI it should work, and I don't think we
need it anywhere else.
Alternatively, we can wrap tag retrieval in some function to mask off
the queue prefix for the cases where we just want an index.
Would probably be better to have a tag generation function instead, that
uses rq->tag and ORs in the queue prefix, actually. That way rq->tag
would remain being a plain index, and the issued tag in the driver could
then use some function to add the queue prefix, if it needs unique tags
across queues in a shared tag set.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
