This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On May 27, 2007, at 10:23 AM, Galen Shipman wrote:
>>> The problem is that MCA_BTL_DES_FLAGS_PRIORITY was meant to
>>> 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
>> devel mailing list
> devel mailing list