Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Allocate free list payload if free list isn't specified
From: Rolf vandeVaart (rvandevaart_at_[hidden])
Date: 2012-02-21 16:31:51

I think I am OK with this.

Alternatively, you could have done something like is done in the TCP BTL where the payload and header are added together for the frag size?
To state more clearly, I was trying to say you could do something similar to what is done at line 1015 in btl_tcp_component.c and ended up with the same results?

This is just making the payload buffer a different chunk of memory than the headers?

I am just trying to understand the motivation for the change.

I think the way you have it is more correct so we can support the case where someone specifies the header size and the payload size differently and expects the free list code to do the right thing.


>-----Original Message-----
>From: devel-bounces_at_[hidden] [mailto:devel-bounces_at_[hidden]]
>On Behalf Of Nathan Hjelm
>Sent: Tuesday, February 21, 2012 3:59 PM
>To: Open MPI Developers
>Subject: Re: [OMPI devel] RFC: Allocate free list payload if free list isn't
>Opps, screwed up the title. Should be: RFC: Allocate requested free list
>payload even if an mpool isn't specified.
>On Tue, 21 Feb 2012, Nathan Hjelm wro
>> What: Allocate free list payload even if a payload size is specified
>> even if no mpool is specified.
>> When: Thursday, Feb 23, 2012
>> Why: The current behavior is to ignore the payload size if no mpool is
>> specified. I see no reason why a payload buffer should't be allocated
>> in the no mpool case. Thoughts?
>> Patch is attached.
>> -Nathan Hjelm
>> HPC-3, LANL
>devel mailing list
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.