Date: Sat, 14 Mar 2009 01:06:23 +0000 From: Bruce Simpson <bms@incunabulum.net> To: "Sean C. Farley" <scf@FreeBSD.org> Cc: freebsd-net@FreeBSD.org, Rui Paulo <rpaulo@FreeBSD.org> Subject: Re: tap(4) SIOCSIFMTU patch Message-ID: <49BB030F.5010201@incunabulum.net> In-Reply-To: <alpine.BSF.2.00.0903131837040.7444@thor.farley.org> References: <alpine.BSF.2.00.0903122048230.1704@thor.farley.org> <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> <alpine.BSF.2.00.0903130918400.4522@thor.farley.org> <49BAE99B.2030508@incunabulum.net> <alpine.BSF.2.00.0903131837040.7444@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49BB030F.5010201>