On Sun, May 27, 2007 at 10:23:23AM -0600, Galen Shipman wrote:
> >>
> >>
> >> 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.
You a right. We kinda rely on PML here. PML always send "max send" sized
packets with low priority.
>
> 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.
Sometimes prepare_src may return eager sized fragment and it will be
sent on low priority QP.
--
Gleb.
