For non-fabric controllers, the corresponding I/O qpairs are simply re-enabled at controller reset. This had a issue when I/O qpairs span multiple threads and poll group is used. spdk_nvme_ctrlr_reconnect_poll_async() calls nvme_transport_ctrlr_connect_qpair() with qpair->async being false. Then nvme_transport_ctrlr_connect_qpair() calls spdk_nvme_poll_group_process_completions() until the qpair is connected. spdk_nvme_poll_group_process_completions() may poll other qpairs. This may cause I/O to complete on a wrong thread. For PCIe controller, spdk_nvme_poll_group_process_completions() calls spdk_nvme_qpair_process_completions() simply for each qpair. Hence change nvme_transport_ctrlr_connect_qpair() to call spdk_nvme_qpair_process_completions() if the controller is non-fabrics. Signed-off-by: Shuhei Matsumoto <smatsumoto@nvidia.com> Change-Id: Ieb270c2fb154124021ef6d25577b817d05e5ca9e Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/14295 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Michael Haeuptle <michaelhaeuptle@gmail.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Dong Yi <dongx.yi@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@nvidia.com> |
||
---|---|---|
.. | ||
Makefile | ||
nvme_transport_ut.c |