> -----Original Message----- > From: Sagi Grimberg [mailto:sagig@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, April 16, 2014 10:18 AM > To: Steve Wise; 'Chuck Lever'; linux-nfs@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 7/8] xprtrdma: Split the completion queue > > 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! > Thank you! :) In fact, chelsio HW doesn't do ANY flushing. It is all done in software at the time the QP exits RTS... Stevo -- 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
