74cd76db68
This test reproduced issue #2428. It does the following: 1) submit some large writes (requiring R2T or RDMA READ) 2) submit fused compare (first fused) 3) variable number of qpair polls 4) submit fused write (second fused) The RDMA and TCP transports were not accounting for the fused bits, and would send a non-fused command down to the target layer between the two fused commands. By adding the variable amount of delay between the fused command submissions, it creates a window where a large write's payload is fetched from the host and submitted to the target between submission of the two fused commands. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I1abd5a6bca08386279c09f8135387826149d30ef Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11963 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| fused_ordering.c | ||
| Makefile | ||