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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
