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-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
