Date: Fri, 13 Mar 2009 18:53:57 -0500 (CDT) From: "Sean C. Farley" <scf@FreeBSD.org> To: Bruce Simpson <bms@incunabulum.net> Cc: freebsd-net@FreeBSD.org, Rui Paulo <rpaulo@FreeBSD.org> Subject: Re: tap(4) SIOCSIFMTU patch Message-ID: <alpine.BSF.2.00.0903131837040.7444@thor.farley.org> In-Reply-To: <49BAE99B.2030508@incunabulum.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Mar 2009, Bruce Simpson wrote: > Sean C. Farley wrote: >> >> Yes, this fixes my issue with bridging a tap device to an interface >> with an MTU higher than 1500. I will probably commit this patch this >> weekend. > > I can't think of any reason why not, other than you might want to > ensure that tap's MTU is bounded within reasonable limits, 'cause yoi > don't want to exhaust the jumbo cluster pool if say mtu is more than > 9000. I was letting ifhwioctl() perform the MTU limit check. It insures: IF_MINMTU <= ifr->ifr_mtu <= IF_MAXMTU I admitted to being new. See! :) 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. > 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? Sean -- scf@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903131837040.7444>