Brian,
I have few questions/comments about the proposed approach:
1. The BML endpoint structure (aka. BML proc) is well known and defined in the
bml.h. So it is not technically opaque…
2. When allocating an ompi_proc_t structure you will always have to allocate
for an array large enough to con
+1, though I do have a question.
We are looking at exascale requirements, and one of the big issues is memory
footprint. We currently retrieve the endpoint info for every process in the
job, plus all the procs in any communicator with which we do a connect/accept -
even though we probably will
+1, but I helped come up with the idea. :-)
On Jul 18, 2013, at 5:32 PM, "Barrett, Brian W" wrote:
> What: Change the ompi_proc_t endpoint data lookup to be more flexible
>
> Why: As collectives and one-sided components are using transports
> directly, an old problem of endpoint tracking is r
