On 03/06/2019 10:54, Ming Lei wrote:
On Mon, Jun 03, 2019 at 09:57:26AM +0100, John Garry wrote:
Otherwise duplicated slot can be used from different blk-mq hw queue.
The worsen thing is that V3's actual max queue depth is (4096 - 96), but
this patch claims that the device can support (4096 - 96) * 32 command
slots
To be clear about the hw, the hw supports max 4096 command tags and has 16
Is 4096 the max allowed host-wide command tags? Or per-queue's max commands
tags?
4096 is max allowed host wide, in range [0, 4096), and tags are not per
queue. HW delivery queues can be configured to be as large as desired.
Then all delivery(and complete) queues share the 4096 command slots, we can't
convert hisi_sas V3 into typical blk-mq MQ model simply as done by Hannes's patch.
Or you may partition the 4096 tags into 16 queues, then each queue's
depth is ~256. Depends on if performance is good for workloads.
You still can build a unique tag easily in [0, 4096), such as
(req->tag * hw_queue_index).
blk-mq's hw queue has independent tags, which is from NVMe's submission/completion
queue.
ehhhh, and this is what I thought you were addressing in "[PATCH 1/9]
blk-mq: allow hw queues to share hostwide tags", right?
And on another point I saw mentioned, the device supports multiple
submission and multiple completion queues. They are symmetrical, and any
command will always complete on the same queue index which it was submitted.
DQ & CQ did confuse me a bit, :-)
DQ is "delivery" queue. Interna; terminolgy.
In response to earlier "It depends on if hisi_sas V3 hardware supports
independent tags for each queue. "
As you now know, it doesn't.
TBH, I would be slightly surprised if any SCSI host supported
independent tags per HW queue (ignoring these tri-mode types). The
reason is that hisi_sas uses this tag as SAS SSP frame tag, and later
used for TMF tag. If we sent different commands to a SCSI end device
from different queues, then possibly non-unique tags and this would
break the model. But maybe other SCSI host work differently.
Thanks,
John
Thanks,
Ming
.
