Re: Retiring dhclient

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 24 Nov, 2011, at 11:50 , David Laight wrote:
> On Thu, Nov 24, 2011 at 07:10:31PM +0100, Joerg Sonnenberger wrote:
>> 
>> Does anyone know how long PHY resets for affected cards take?
> 
> Link negotiation can take a while ....
> 
> I'm surprised that reducing the mtu can ever require a MAC reset.
> Especially since you want to be able to set a per-path mtu.
> Maybe the MACs that can do IP segmentation for large TCP??
> 
> I also suspect it would be useful to set different values for
> the rx and tx mtu.  I know I've seen systems that reject 1500
> byte packets when the mtu is set shorter (to avoid an external
> mtu blackhole).
> 
> Or rather tell IP the max mtu to send, rather then telling the
> MAC driver.

I was just going to ask this too.  The IP MTU you receive
via DHCP or PPP is just an IP MTU, it should have no effect on
my-very-own-network-protocol which may be sharing the same
interface hardware, so I don't want an IP MTU change to somehow
have the effect of reducing the size of frames the interface
hardware is willing to send and receive.  More than this,
if it isn't otherwise inconvenient or somehow costly I would
prefer that all my network hardware interfaces be set to
receive the largest frames they are physically capable of
receiving for a number of reasons including, but not limited
to, the "be conservative in what you send, be liberal in what
you accept" dictum, no matter what size the protocols are
configured to send.  The "T" in MTU is "Transmit", there isn't
a reason for it to constrain what you receive.

That would mean the only time I might ever want to tell my MAC
chip an interface MTU is for some kind of IP offload functions.
I wonder what that those functions would be, since most of the
things I can think of which might use that number don't seem
all that useful?

Dennis Ferguson