tap(4) SIOCSIFMTU patch

[Bruce Simpson]

Sean C. Farley wrote:
> ...
> Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16], 
> yes?  em(4) has an upper limit of 16114 for MTU.  I could limit the 
> MTU to TAPMRU (16384) which is the limit for a write to the driver 
> anyway.
Just waiting for my VFS cache to spool up after a fresh boot with the 
KScope goggles on...

Sounds realistic. I seem to recall that whilst IPv6 will allow for truly 
massive datagrams, the KAME implementation didn't support up to the full 
size.

I can't believe that's going to be a real issue, though. Even lo(4) 
won't bump its MTU up to 128KB unless told to (LARGE_LOMTU def).
It's hardcoded for lo(4).
In this case it probably isn't anyting to worry about -- it's pilot 
error, for now, if the MTU is set too high on an ifnet.

You just need to keep an eye out for it, because tap(4) relies utterly 
on m_uiotombuf() on the U->K path, and it will try to allocate jumbo 
clusters upfront first thing.

>
>> I think ifconfig already performs such a check but you might want to 
>> double check.
>
> I noticed that ifconfig can report JUMBO_MTU, but few drivers actually 
> flag it.  Should I set this for tap?

I don't think it's going to be a problem. lo(4) just passes the MTU down 
to the ifnet struct as your patch does.

Go ahead and commit! And thanks!

cheers,
BMS