If it is Mellanox specific, maybe the component name could reflect this (like
mlxhcoll), as it will be visible to end-users.
Aurelien
Le 18 juin 2013 à 11:25, "Barrett, Brian W" a écrit :
> In general, I'm ok with it. I think we should let it soak for a week or
> two
George replied to me in IM -- posting here for completeness:
> Yes, there is a reason. if sendi succeeds, it sends a very small data (at
> least on the devices that supports it), otherwise it returns a descriptor
> similar to btl_alloc()
> thus you will have to pack the data yourself, and the
No one cared today on the call. So I'll be removing the old IMB 3.2 and 3.2.3
directories from ompi-tests later today.
Go update your MTT configurations to use the new "imb" directory.
On Jun 14, 2013, at 12:00 PM, Jeff Squyres (jsquyres)
wrote:
> I'm sorry -- I was
Hello,
Jiri Hladky, le Tue 18 Jun 2013 17:18:15 +0200, a écrit :
> I would like to check the possibilities to visualize the results to the output
> similar to lstopo --top (see the attachment). I would like to write a simple
> utility which will
> * parse the above file
> * foreach timestep
In general, I'm ok with it. I think we should let it soak for a week or
two in the trunk before we file the CMR to 1.7.
Brian
On 6/18/13 6:51 AM, "Jeff Squyres (jsquyres)" wrote:
>Sounds good; +1.
>
>On Jun 18, 2013, at 8:02 AM, Joshua Ladd wrote:
>
Sounds good; +1.
On Jun 18, 2013, at 8:02 AM, Joshua Ladd wrote:
> Request for Change:
>
> What: Add support for Mellanox Technologies’ next-generation non-blocking
> collectives, code-named “libhcoll”. This comes in the form of a new “hcoll”
> component to the “coll”
Request for Change:
What: Add support for Mellanox Technologies' next-generation non-blocking
collectives, code-named "libhcoll". This comes in the form of a new "hcoll"
component to the "coll" framework.
Where: Trunk and 1.7
When: July 1
Why: In support of MPI 3, Mellanox Technologies will