On Nov 30, 2006, at 2:16 PM, Scott Atchley wrote:
I am thinking about how to handle BMI_mx_memalloc(). I might be
able to assist the reg cache in MX if I do things a certain way.
I mention this below, on the server we always call BMI_memalloc to
allocate buffers and post them to BMI_post_se
On Dec 1, 2006, at 12:53 PM, Sam Lang wrote:
It looks like the flow code on the server doesn't actually post
the next recv of IO (IO2), until the first recv has completed
(IO1), so its possible that the client posts (and starts) the
next send before the server posts the next receive, althou
On Dec 1, 2006, at 7:10 AM, Scott Atchley wrote:
On Dec 1, 2006, at 4:33 AM, Sam Lang wrote:
Your example above is currently how writes work. The client sends
an unexpected message to the server (a control message for the IO,
file info, size of the IO, etc.), which posts an expected recei
On Dec 1, 2006, at 4:33 AM, Sam Lang wrote:
Your example above is currently how writes work. The client sends
an unexpected message to the server (a control message for the IO,
file info, size of the IO, etc.), which posts an expected receive,
and then sends an expected back to the client.
On Nov 30, 2006, at 6:58 PM, Scott Atchley wrote:
On Nov 30, 2006, at 4:31 PM, Sam Lang wrote:
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 desi
On Nov 30, 2006, at 4:31 PM, Sam Lang wrote:
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 o
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 u
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_re
On Nov 30, 2006, at 1:16 PM, Scott Atchley wrote:
On Nov 30, 2006, at 12:13 PM, Sam Lang wrote:
On Nov 30, 2006, at 9:27 AM, Scott Atchley wrote:
Hi all,
No one replied the the original post. The one I am most curious
about is (3). Is FlowBufferSizeBytes available to the BMI
implementa
On Nov 30, 2006, at 12:13 PM, Sam Lang wrote:
On Nov 30, 2006, at 9:27 AM, Scott Atchley wrote:
Hi all,
No one replied the the original post. The one I am most curious
about is (3). Is FlowBufferSizeBytes available to the BMI
implementations?
Hi Scott,
Sorry for not responding. I've i
On Nov 30, 2006, at 9:27 AM, Scott Atchley wrote:
Hi all,
No one replied the the original post. The one I am most curious
about is (3). Is FlowBufferSizeBytes available to the BMI
implementations?
Hi Scott,
Sorry for not responding. I've included responses to your questions
inline.
Hi all,
No one replied the the original post. The one I am most curious about
is (3). Is FlowBufferSizeBytes available to the BMI implementations?
I am thinking about how to handle BMI_mx_memalloc(). I might be able
to assist the reg cache in MX if I do things a certain way.
Scott
On Oct
Hi all,
A few quick questions:
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)?
2. If there is a limit in the above and it is greater than 1, is that
value the same for small (unexpected and some expected)
Sam Lang wrote:
On Aug 17, 2006, at 7:49 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 17 Aug 2006 18:14 -0500:
* BMI memory allocation. Do we place any restrictions on when or how
frequently BMI_memalloc is called? In the pvfs code, we always call
BMI_memalloc for a post_send or
I have some questions related to the design semantics of BMI.
* timeouts. It looks like the timeout for bmi test calls is the max
amount of time spent _idling_ in the test call (as apposed to the max
time spent in the test call).
This is correct. The name of the argument is max_idle_tim
On Aug 17, 2006, at 7:49 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Thu, 17 Aug 2006 18:14 -0500:
* BMI memory allocation. Do we place any restrictions on when or how
frequently BMI_memalloc is called? In the pvfs code, we always call
BMI_memalloc for a post_send or post_recv. Would
[EMAIL PROTECTED] wrote on Thu, 17 Aug 2006 18:14 -0500:
> * BMI memory allocation. Do we place any restrictions on when or how
> frequently BMI_memalloc is called? In the pvfs code, we always call
> BMI_memalloc for a post_send or post_recv. Would it be possible to
> avoid the malloc on t
Hi all,
I have some questions related to the design semantics of BMI.
* timeouts. It looks like the timeout for bmi test calls is the max
amount of time spent _idling_ in the test call (as apposed to the max
time spent in the test call). In other words, if operations are
being completed
18 matches
Mail list logo