<br><tt><font size=2>Roland Dreier wrote:</font></tt>
<br>
<br><tt><font size=2>> > > It would be nice, but to handle increasing
the MTU, you need some way<br>
> > > to handle the receives you already posted (which would be
too small<br>
> > all of a sudden).<br>
><br>
> > Can you expand on this a little more -I do not catch the drift.<br>
><br>
> OK, suppose I configure the interface with a 16K MTU. I assume
your<br>
> plan would be to queue up a bunch of 16K receives. Now suppose
I<br>
> change the MTU to 64K. What do you do about the receives you
already<br>
> queued up that can't handle the new MTU?<br>
></font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>What happens to Ethernet when you turn on or off jumboframes?</font></tt>
<br><tt><font size=2><br>
> - R.<br>
></font></tt>
<br><font size=2 face="sans-serif"><br>
Bernie King-Smith <br>
IBM Corporation<br>
Server Group<br>
Cluster System Performance <br>
wombat2@us.ibm.com (845)433-8483<br>
Tie. 293-8483 or wombat2 on NOTES <br>
<br>
"We are not responsible for the world we are born into, only for the
world we leave when we die.<br>
So we have to accept what has gone before us and work to change the only
thing we can,<br>
-- The Future." William Shatne</font>