The overflow condition can't happen unless there is a programming error
in the nvmf_tgt library; we can only possibly receive command capsules
(sq entries from the point of view of the host) if we have posted a RDMA
Recv for the command capsule memory region.
This means that we also don't need to track sq_tail in the NVMf library.
Change-Id: I101509080c744528871e72fa46d188e2850c928a
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
These are an implementation detail of RDMA, so move
them into the RDMA portion of the connection.
Change-Id: I68d146019c5d78fbf5e9968abfd7baed2a54a2ed
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Separate out the RDMA connection from the
NVMf connection. For now, the RDMA connection
is just embedded in the NVMf connection, but
eventually they will have different lifetimes.
Change-Id: I9407d94891e22090bff90b8415d88a4ac8c3e95e
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
Instead of searching the global list of connections to find a matching
cm_id, we can just store the pointer back to the spdk_nvmf_conn in the
rdma_cm_id context field.
Change-Id: I39ea16be6a633a1136d65743747b63b600f20e63
Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
If we just pass NULL to rdma_create_qp, it will do
the right thing.
Change-Id: I9621a5110ace6237a1e47c6e5defb4cac3afc4ae
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
