add object size to opal class
no longer need the size when allocating a new object as this is stored in
the class structure
--- dr changes
Previous rev. maintained state on the communicator used for acking duplicate
fragments, but the communicator may be destroyed prior to successfull
delivery of an ack to the peer. We must therefore maintain this state
globally on a per peer, not a per peer, per communicator basis.
This requires that we use a global rank on the wire and translate this as
appropriate to a local rank within the communicator.
This commit was SVN r9454.
default
* Add ability to start Put and Get requests immediately instead of queuing
until synchronizaion when using Fence. Not entirely sure this is
completely safe, so it must be explicitly enabled by the user, either with
an MCA parameter or info argument to Win_create.
This commit was SVN r9418.
only as a pointer reference completely confuse some compilers (gcc 4.1
included). Removing the inline (it was there before when the function
was used in the same file) seems to solve the problem. However, the most
strange thing is that the bug only appear when we compile directly in
the trunk directory. It just don't happens when we're using the VPATH
build.
This commit was SVN r9408.
* Install peruse.h in $includedir, since applications need to be able
to include it as <peruse.h>
* Fix issue with onesided code always installing it's headers
This commit was SVN r9405.
- Grab the mpool_registration in _frag_common_constructor()
- Save the LMR context in the segment key
- No need for cookie variables - can just cast the frag
- No need to memcpy() data when recv'ing
- Add an LMR triplet to the fragment structure and initialize it
in btl_udapl_alloc().
- Whitespace/typo fixes, remove some opal_output() calls
Looks like I can use triplets describing sub-regions of registered LMR's. So I
do this - prior to this patch I was sending the entire free list memory over,
which isn't correct :)
Back to an earlier problem - when sending address information right after
connection establishment, the receiving end receives a DTO completion event and
appears to have good data. But the sending end never receives a DTO completion
event indicating the send completed, and never completes the client side of the
connection.
This commit was SVN r9386.
In short, I'm very close to having connection establishment and eager send/recv working.
Part of the connection process involves sending address information from the
client to server. For some reason, I am never receiving an event indicating
completetion of the send on the client side. Otherwise, connection
establishment is working and eager send/recv should be trivial from here.
Some more detailed changes:
- Send partially implemented, just handles starting up new connections.
- Several support functions implemented for establishing connection. Client
side code went in btl_udapl_endpoint.c, server side in btl_udapl_component.c
- Frags list and send/recv locks added to the endpoint structure.
- BTL sets up a public service point, which listens for new connections.
Steps over ports that are already bound, iterating through a range of ports.
- Remove any traces of recv frags, don't think I need them after all.
- Pieces of component_progress() implemented for connection establishment.
- Frags have two new types for connection establishment - CONN_SEND and
CONN_RECV.
- Many other minor cleanups not affecting functionality
This commit was SVN r9345.
