[ofa-general] IPOIB CM (NOSRQ) patch -memory footprint

[Bernard King-Smith]

Roland Dreier wrote:

> > > It would be nice, but to handle increasing the MTU, you need some 
way
> > > to handle the receives you already posted (which would be too small
> > all of a sudden).
>
> > Can you expand on this a little more -I do not catch the drift.
>
> OK, suppose I configure the interface with a 16K MTU.  I assume your
> plan would be to queue up a bunch of 16K receives.  Now suppose I
> change the MTU to 64K.  What do you do about the receives you already
> queued up that can't handle the new MTU?
>

When you change the MTU you have to build a new set of receive buffers at 
the new MTU and before advertising the new MTU, and associate the new 
buffers and associated structures with the current interfaces. This leaves 
the old buffers structures to be handled appropriately by separate 
threads. When all older buffers are released/returned, you tear everything 
down and terminate threads associated with the old MTU. If you find that a 
set of receive buffers are empty when starting to change the MTU, you can 
go immediately to the new size. This minimizes the memory needed during 
the change in MTU.

As soon as youchange teh local interface to a diferent MTU, it will be a 
while before the remote connections find out and change the MTU they send.

What happens to Ethernet when you turn on or off jumboframes?

>  - R.
>

Bernie King-Smith 
IBM Corporation
Server Group
Cluster System Performance 
wombat2 at us.ibm.com    (845)433-8483
Tie. 293-8483 or wombat2 on NOTES 

"We are not responsible for the world we are born into, only for the world 
we leave when we die.
So we have to accept what has gone before us and work to change the only 
thing we can,
-- The Future." William Shatne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20070525/7ee9f99e/attachment.html>