Hello Jens,

Multiple block drivers need the functionality to stop a request queue and to wait until all ongoing request_fn() / queue_rq() calls have finished without waiting until all outstanding requests have finished. Hence this patch series that introduces the blk_mq_quiesce_queue() and blk_mq_resume_queue() functions. The dm-mq, SRP and NVMe patches in this patch series are three examples of where these functions are useful. These patches have been tested on top of kernel v4.9-rc1. The following tests have been run to verify this patch series:
- My own srp-test suite that stress-tests SRP on top of dm-multipath.
- Mike's mptest suite that stress-tests dm-multipath.
- fio on top of the NVMeOF host driver that was connected to the NVMeOF
  target driver on the same host.
- Laurence verified the previous version (v2) of this patch series by
  running it through the Red Hat SRP test suite. Laurence also ran some
  NVMe tests (thanks Laurence!).

The changes compared to the second version of this patch series are:
- Changed the order of the patches in this patch series.
- Added several new patches: a patch that avoids that .queue_rq() gets
  invoked from the direct submission path if a queue has been stopped
  and also a patch that introduces the helper function
- blk_mq_quiesce_queue() has been reworked (thanks to Ming Lin and Sagi
  for their feedback).
- A bool 'kick' argument has been added to blk_mq_requeue_request().
- As proposed by Christoph, the code that waits for queuecommand() has
  been moved from the SRP transport driver to the SCSI core.

Changes between v2 and v1:
- Dropped the non-blk-mq changes from this patch series.
- Added support for harware queues with BLK_MQ_F_BLOCKING set.
- Added a call stack to the description of the dm race fix patch.
- Dropped the non-scsi-mq changes from the SRP patch.
- Added a patch that introduces blk_mq_queue_stopped() in the dm driver.

The individual patches in this series are:



To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to