Ciprian,
> I know that lustrefs is using its own implementation of portals, but if
> they comply with the specification it should not make a difference with
> my problem.
LNET (lustre networking) is not portals. It has a lot in common with
portals - it also has MEs and MDs and supports GET and PUT operations, but
in other respects - e.g how it supports multiple networks, unlink semantics
- it is quite different.
> What communication model is lustre using: one side or two side transfers
Both sort of - the fundamental unit is the RPC...
0. Server ensures sufficient ME/MDs posted at all times to receive RPC
requests.
1. Client attaches ME/MD for RPC reply and any bulk data buffers.
2. Client PUTs an RPC request.
3. Server PUTs/GETs any bulk data.
4. Server PUTs RPC reply.
> How do you deal with bursts of transfers ? let''s say the initiator
(A)
> wants to transfer a certain amount of data at very short periods of
> time; what model do you use for transfers (portals get or put) ?
See above.
> In case of a "put" how can you make sure that successive
transfers will
> not overwrite previous data on the target side ?
Every communication apart from the initial RPC request is guaranteed to
match a unique buffer in the peer since the client pre-posts bulk and rpc
reply buffers.
Servers grow the RPC request buffer pool dynamically. LNET stalls incoming
PUTs if this pool is temporarily exhausted to give the server time to grow
the pool and ensure PUTs are only dropped if memory allocation to grow the
pool fails.
Cheers,
Eric
---------------------------------------------------
|Eric Barton Barton Software |
|9 York Gardens Tel: +44 (117) 330 1575 |
|Clifton Mobile: +44 (7909) 680 356 |
|Bristol BS8 4LL Fax: call first |
|United Kingdom E-Mail: eeb@bartonsoftware.com|
---------------------------------------------------