Caitlin Bestler wrote:
[snip]
> The DAPL semantics are very clear that send/recv operations must
> be matched one to one, that the receive buffer must be large
> enough for the received message and that there must be a receive
> buffer for each incoming send/recv message. That means that
> the
More like trying to work around the race condition that exists: The
server side sends an rdma message first thus violating the iwarp
protocol. For those who want the gory details: when the server sends
first -and- that rdma message arrives at the client _before_ the
client
transitions into
Donal Kerr wrote:
>>> order of business after connection establishment
>>> (mba_btl_udapl_sendrecv(). The RECV buffer post for this exchange,
>>> however, should really be done _before_ the
>>> dat_ep_connect() on the active side, and _before_ the
>>> dat_cr_accept() on the server side.
>>>
On Thu, 2007-05-10 at 23:10 -0400, Donald Kerr wrote:
>
> Caitlin Bestler wrote:
>
> >devel-boun...@open-mpi.org wrote:
> >
> >
> >>>There are two new issues so far:
> >>>
> >>>1) this has uncovered a connection migration issue in the Chelsio
> >>>driver/firmware. We are developing and
Steve --
Can you file a trac bug about this?
On May 10, 2007, at 6:15 PM, Steve Wise wrote:
There are two new issues so far:
1) this has uncovered a connection migration issue in the Chelsio
driver/firmware. We are developing and testing a fix for this now.
Should be ready tomorrow
devel-boun...@open-mpi.org wrote:
>> There are two new issues so far:
>>
>> 1) this has uncovered a connection migration issue in the Chelsio
>> driver/firmware. We are developing and testing a fix for this now.
>> Should be ready tomorrow hopefully.
>>
>
> I have a fix for the above issue and
>
> There are two new issues so far:
>
> 1) this has uncovered a connection migration issue in the Chelsio
> driver/firmware. We are developing and testing a fix for this now.
> Should be ready tomorrow hopefully.
>
I have a fix for the above issue and I can continue with OMPI testing.
To
