Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Gleb Natapov (glebn_at_[hidden])
Date: 2007-06-07 16:23:38


On Thu, Jun 07, 2007 at 02:38:51PM -0400, George Bosilca wrote:
>
> 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
The intention is that most of the time PML will use NO_ORDER, but
sometimes order is important.

> 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
BTL_OPENIB_LP_QP is never used in PML code. It just like some kind of
cookie that is transparent to PML. You don't claim that we expose BTL
internals if BTL setups callback for PML to use, don't 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).
OpenIB and UDAPL are only two BTLs that can reorder packets currently, so
we have two choses here. We can prohibit from BTL to reorder packets or we
have to provide a way to insure ordering between certain packets. The
former will limit BTL interface IMHO.

>
> 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.
>
Galen currently works on adding arbitrary number of different sized
queues in openib BTL. There will be much more then two queues. This kind
of thing is really internal to BTL.

--
			Gleb.