> On Sun, May 27, 2007 at 10:34:33AM -0600, Galen Shipman wrote:
>> Actually, we still need MCA_BTL_FLAGS_FAKE_RDMA , it can be used as
>> a hint for components such as one-sided.
> What is the purpose of the hint if it should be set for each interconnect.
> Just assume that it is set and behave a
On Sun, May 27, 2007 at 10:34:33AM -0600, Galen Shipman wrote:
> Actually, we still need MCA_BTL_FLAGS_FAKE_RDMA , it can be used as
> a hint for components such as one-sided.
What is the purpose of the hint if it should be set for each interconnect.
Just assume that it is set and behave accordi
On Sun, May 27, 2007 at 10:32:26AM -0600, Galen Shipman wrote:
> Can we get rid of mca_pml_ob1_send_fin_btl and just have
> mca_pml_ob1_send_fin? It seems we should just always send the fin
> over the same btl and this would clean up the code a bit.
Yes. It should be possible. I'll do that.
>
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,
> >>
On Sun, May 27, 2007 at 10:19:09AM -0600, Galen Shipman wrote:
>
> > With current code this is not the case. Order tag is set during a
> > fragment
> > allocation. It seems wrong according to your description. Attached
> > patch fixes
> > this. If no specific ordering tag is provided to alloca
Actually, we still need MCA_BTL_FLAGS_FAKE_RDMA , it can be used as
a hint for components such as one-sided.
Galen
On May 27, 2007, at 5:25 AM, g...@osl.iu.edu wrote:
Author: gleb
Date: 2007-05-27 07:25:39 EDT (Sun, 27 May 2007)
New Revision: 14782
URL: https://svn.open-mpi.org/trac/ompi/c
Can we get rid of mca_pml_ob1_send_fin_btl and just have
mca_pml_ob1_send_fin? It seems we should just always send the fin
over the same btl and this would clean up the code a bit.
Thanks,
Galen
On May 27, 2007, at 2:29 AM, g...@osl.iu.edu wrote:
Author: gleb
Date: 2007-05-27 04:29:38
doh,, correction..
On May 27, 2007, at 10:23 AM, 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 th
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
With current code this is not the case. Order tag is set during a
fragment
allocation. It seems wrong according to your description. Attached
patch fixes
this. If no specific ordering tag is provided to allocation
function order of
the fragment is set to be MCA_BTL_NO_ORDER. After call to s
On Fri, May 25, 2007 at 09:31:33PM -0600, Galen Shipman wrote:
>
> On May 24, 2007, at 2:48 PM, George Bosilca wrote:
>
> > I see the problem this patch try to solve, but I fail to correctly
> > understand the implementation. The patch affect all PML and BTL in
> > the code base by adding one
11 matches
Mail list logo
