Fix request completion holes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] Fix request completion holes
Quoted 1 line · Sagi Grimberg
the default mode utilize remote invalidation, so no, its not valid.
Well, usually the ULP design should allow some things to be reaped async, and latency senstive things to be sync.
Eg if you have a SEND using a local buffer with a RKEY, then you'd declare the RKEY data completed when SEND_WITH_INVALIDATE is returned.
Recycling the lkey command buffer is an async process and can wait unsignaled until something signalled comes to push its completion through.
This approach reduces the # of CQEs required at the expense of delaying reaping the lkey buffer.
Quoted 4 lines
Without remote invalidate I'm not sure, don't remember the ordering rules from the top of my head. Idan, does a local invalidate completion guarantee a prior send completion (of a non-related buffer)? I vaguely remember that explicit fencing is required to guarantee that.
This was the case I thought Idan was testing..
Local invalidate is defined to always be ordered by the spec, so it is required to guarentee that the SEND is completed.
Quoted 2 lines
I guess we could not signal send completions if we are in a local invalidate mode, but I'm liking this less and less...
If the SEND reaping can be defered as above, then the local invalidate completion becomes the signaled CQE that allows the SEND to be reaped.
Jason