On 3/7/22 16:39, Mike Christie wrote:
The software iscsi driver's queuecommand can block and taking the extra
hop from kblockd to its workqueue results in a performance hit. Allowing
it to set BLK_MQ_F_BLOCKING and transmit from that context directly
results in a 20-30% improvement in IOPs for workloads like: [...]
That's impressive!
@@ -2952,8 +2954,8 @@ scsi_host_block(struct Scsi_Host *shost)
}
/*
- * SCSI never enables blk-mq's BLK_MQ_F_BLOCKING flag so
- * calling synchronize_rcu() once is enough.
+ * Drivers that use this helper enable blk-mq's BLK_MQ_F_BLOCKING flag
+ * so calling synchronize_rcu() once is enough.
*/
WARN_ON_ONCE(shost->tag_set.flags & BLK_MQ_F_BLOCKING);
s/enable/do not set/ ?
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 72e1a347baa6..0d106dc9309d 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -75,6 +75,10 @@ struct scsi_host_template {
*/
int (* queuecommand)(struct Scsi_Host *, struct scsi_cmnd *);
+ /*
+ * Set To true if the queuecommand function can block.
+ */
+ bool queuecommand_blocks;
/*
* The commit_rqs function is used to trigger a hardware
* doorbell after some requests have been queued with
I'm not sure what the best name is for this new flag. Some function
names refer to sleeping (e.g. might_sleep()) while the flag
BLK_MQ_F_BLOCKING has "blocking" in its name. Although I do not have a
strong opinion about this: has it been considered to use a name like
queuecommand_sleeps or queuecommand_may_sleep instead of
queuecommand_blocks?
Thanks,
Bart.
