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
> another solution. I also didn't like this change too much, but I
> 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
>> 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
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s