On Nov 30, 2006, at 1:41 PM, Scott Atchley wrote:
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).
Yeah I agree. Its not completely clear to me what happens when a
server gets overloaded, and is probably something we need to look
into. Maybe someone with more experience in the flow and bmi code
knows something I don't though.
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?
Right now all our operations (or transactions, as you call them)
start with an unexpected message from the client, and end with an
expected message from the server. I don't know if that's a design
requirement of BMI though, or just an artifact of how we use it in
PVFS. I _think_ the BMI interfaces were meant to allow expected
messages in either direction in any order, and its left up to the
upper layers to make sure they get posted right, but again, I would
have to defer to one of the BMI sages. Are you able to do some kind
of pre-posting if you know there's always an expected coming back?
-sam
Scott
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
