+18
−2
Loading
If a lot of qpairs are connected all at once, the RDMA optimal_poll_group logic does not work correctly, because it only accounts for qpairs that received their CONNECT capsule. Now that we have a counter for a poll group's unassociated qpairs, use that value to supplement the current io qpair count. We can just assume for now that all of these unassociated qpairs are io qpairs. That won't always be true, but for purposes of picking the optimal poll group it is sufficient. Note that for RDMA, we could increment the counters based on the RDMA qpair ID in the private data in the rdmacm connect, but to keep the code simpler and common across all transports, we defer the accounting until after receiving the CONNECT command, so that it is the same for all transports. Fixes issue #2800. Signed-off-by:Jim Harris <james.r.harris@intel.com> Change-Id: I5897d6ebac23d3b78b100e3fef5a7f9fb5304820 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/15695 Reviewed-by:
Aleksey Marchuk <alexeymar@nvidia.com> Reviewed-by:
Ben Walker <benjamin.walker@intel.com> Reviewed-by:
Konrad Sztyber <konrad.sztyber@intel.com> Tested-by:
SPDK CI Jenkins <sys_sgci@intel.com>