[Pvfs2-developers] BMI questions

[Scott Atchley]

On Nov 30, 2006, at 2:30 PM, Sam Lang wrote:

>>> I mention this below, on the server we always call BMI_memalloc  
>>> to allocate buffers and post them to BMI_post_send/ 
>>> BMI_post_recv.  On the client that's not always the case, the  
>>> user buffer is usually passed directly to BMI_post_send/ 
>>> BMI_post_recv.  Would it help you to know in advance of the post  
>>> (or all posts) what the maximum size of a buffer for  
>>> BMI_post_send/BMI_post_recv is going to be?  We might be able to  
>>> add a BMI info option that other methods could ignore.  We do  
>>> limit it, but its all above the BMI interface that this is done.
>>
>> Knowing the max size in advance helps iff the buffers are  
>> allocated using BMI_memalloc(). If not, it does not matter.
>
> So an extra BMI info option would help on the server?

Possibly. Let's wait to optimize until after the core functionality  
it working. :-)

>>>>> 1. Is there an upper bound on how many transfer operations  
>>>>> between a pair of hosts at any one time (i.e. between a client  
>>>>> and host)?
>>>
>>> There is a max of unexpected requests (UnexpectedRequests option  
>>> in the config file, defaults to 50).  This limits the number of  
>>> unexpected messages that can be handled at once by the server,  
>>> but doesn't limit the number of IO operations (large expected  
>>> messages).
>>
>> I read this as the server will only service up to 50 unexpected  
>> request, but that the client (or clients) can send more. Is that  
>> correct?
>
> Yes that's correct.  There's no limit on unexpected messages a  
> client can send to one particular, or any number of servers.

This makes me worry about overwhelming a server again (i.e. the need  
for flow control).

In all transactions, the client initiates it using an unexpected. Do  
all transactions end with the server sending an expected message to  
the client (regardless of how many intermediate sends the client and  
server send back and forth)? Or is it possible that the last message  
is an expected send from a client to the server?

Scott