On 4/16/2014 5:43 PM, Steve Wise wrote:
Hmm, But if either FASTREG or LINV failed the QP will go to error state
and you *will* get the error wc (with a rain of FLUSH errors).
AFAICT it is safe to assume that it succeeded as long as you don't get
error completions.
But if an unsignaled FASTREG is posted and silently succeeds, then the next
signaled work
request fails, I believe the FASTREG will be completed with FLUSH status, yet
the operation
actually completed in the hw.
Actually if (any) WR successfully completed and SW got it as FLUSH error
it seems like a bug to me.
Once the HW processed the WQ entry it should update the consumer index
accordingly thus should not happen.
Aren't you assuming a specific hardware design/implementation? For cxgb4, the
fact that a work request was consumed by the HW from the host send queue in no
way indicates it is complete. Also, the RDMA specs specifically state that the
rnic/hca implementation can only assume an unsignaled work request completes
successfully (and make its slot in the SQ available for the ULP) when a
subsequent signaled work request completes successfully. So if the next
signaled work request fails, I believe the completion status of prior
unsignaled work requests is indeterminate.
Well actually I wasn't, I just assumed that FLUSH errors will come for
all WQ entries in the range {CI, PI}.
I get it, if a suppressed WQe was consumed and QP went to error state
before a completion was placed, HW may flush it as well.
I agree this may happen. Thanks!
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
