On Jun 7, 2007, at 1:28 PM, Gleb Natapov wrote:

On Thu, Jun 07, 2007 at 11:11:12AM -0400, George Bosilca wrote:
) I expect you to revise the patch in order to propose a generic
solution or I'll trigger a vote against the patch. I vote to be
backed out of the trunk as it export way to much knowledge from the
Open IB BTL into the PML layer.
The patch solves real problem. If we want to back it out we need to find another solution. I also didn't like this change too much, but I thought
about other solutions and haven't found something better that what
Galen did. If you have something in mind lets discuss it.

Well, I didn't really investigate this matter, as for all devices where I work this never happens. What really bother me, and which is not as Galen describe it is the following line:

frag->base.order = order

As the value of "order" come from the PML level and the Open IB BTL use it without any change, to me it means that some knowledge belonging to the BTL (BTL_OPENIB_LP_QP is clearly Open IB related isn't it?) has ben exported to the PML. You can turn it any way you want, this clearly means that the PML is able to give direct orders to the BTL which allow it to put the fragment in the high or low priority queue (which is a VERY Open IB feature).

Now, if we create a constant MCA_BTL_HP_QUEUE it might look better. But, again as all others BTLs will completely ignore this, it look like a Open IB feature exported to the PML to me.



As a general comment this kind of discussion is why I prefer to send
significant changes as a patch to the list for discussion before
committing.


  george.

PS: With Gleb changes the problem is the same. The following snippet
reflect exactly the same behavior as the original patch.
I didn't try to change the semantic. Just make the code to match the
semantic that Galen described.

You didn't change compared with Galen patch. But the same knowledge export happens with your patch (for the same reasons as described above).


--
                        Gleb.
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to