Andrew Gallatin wrote:
> Garrett D'Amore writes:
> > The problem here is that the only reason to lower the MTU is to deal
> > with cases where Path MTU discovery fails. For example, lowering the
> > MTU because your upstream provider doesn't properly deal with frames
> > larger than a PPP size or somesuch.
> >
> > Its frustrating that these cases still exist, but they do. In general,
> > I agree, that lowering the MTU should not be necessary. And indeed,
> > frankly nobody should need to touch the values provided by the media
> > drivers when everything works properly.
>
> You may want to touch the values in order to reduce memory useage if
> you know you cannot use jubmo frames. Since most drivers manage their
> own receive buffers, this can add up. For example, my 10GbE driver,
> depending on load, may allocate up to a (tunable) maximum of 4096
> receive buffers. The difference between 4096 1500b and 9000b frames
> is nearly 30MB.
>
> It would be nice if the driver could be notified that the MTU is
> changing so that it can re-allocate appropriately sized receive
> buffers. Every other *nix that I've worked with does this.
>
Okay, fair enough. :-)
Btw, I am *hopeful* that one day in the future Nemo will provide buffer
management on behalf of drivers. This will address some of the
long-standing races with "loan-up", and free drivers from making poor
decisions as to when to bcopy or use loan up. (Or maybe just allocate a
new DMA or DVMA buffer....)
-- Garrett
> Drew
>
>
