The problem is that MCA_BTL_DES_FLAGS_PRIORITY was meant to indicate
that the fragment was higher priority, but the fragment isn't higher
priority. It simply needs to be ordered w.r.t. a previous fragment,
an RDMA in this case.
But after the change priority flags is totally ignored.
So the priority flag was broken I think, in OpenIB we used the
priority flag to choose a QP on which to send the fragment, but there
was no checking for if the fragment could be sent on the specified
QP. So a max send size fragment could be set as priority and the BTL
would use the high priority QP and we would go bang. This is how I
read the code, I might have missed something.
If the priority flag is simply a "hint" and has hard requirements
than we can still use it in the OpenIB BTL but it won't have any
effect as only eager size fragments can be marked high priority and
we already send these over the high priority QP.
- Galen
--
Gleb.
<patch.diff>
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
