ee31bc9d19
test/ublk/ublk.sh 256 will now create 256 ublk devices, to try to test the ctrlr_cmd queueing logic when the ctrl uring runs out of sqes. It's actually difficult to induce the condition, since the kernel SQPOLL thread can usually keep up with the SPDK process submitting the control commands. The best way to induce it is by *not* stopping the disks at the end of a test with a lot of disks, and letting ublk_destroy_target stop all of them at once. Even then, with the ublk logging enabled, even that extra delay for each commands opcode is enough to help the SQPOLL thread to keep up. Commenting out the first UBLK_DEBUGLOG in ublk_ctrl_cmd() does help it run out of sqes, at least in my setup. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I8f7a6ca29fd69613d44a89adc7e60563b274d155 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/16458 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> |
||
|---|---|---|
| .. | ||
| ublk.sh | ||