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.
Not when using inline data with the send, which is the main issue
here. if we inline data to the command, we will use the local
dma lkey, which does not even have a local invalidate following it.
This approach reduces the # of CQEs required at the expense of
delaying reaping the lkey buffer.
Yes, I understand the advantage of suppressing send completions..
But I'm not very fond of non-trivial behavior depending on all sort of
overly complicated conditions.
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..
Still doesn't mean it is guaranteed to do the right thing :)
Local invalidate is defined to always be ordered by the spec, so it
is required to guarentee that the SEND is completed.
So local invalidate completion is guaranteed to come after all the
completions prior to it in the send queue?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
