From owner-freebsd-net@FreeBSD.ORG Sat Mar 14 01:06:27 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1989106566C; Sat, 14 Mar 2009 01:06:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9334B8FC08; Sat, 14 Mar 2009 01:06:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2D7F82EDF48; Fri, 13 Mar 2009 21:06:27 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 13 Mar 2009 21:06:27 -0400 X-Sasl-enc: 0oU5PeQdeGWNGL9hugRbLu0LROFvTRPzQhrgYAG1wkdY 1236992786 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 897857DFD; Fri, 13 Mar 2009 21:06:26 -0400 (EDT) Message-ID: <49BB030F.5010201@incunabulum.net> Date: Sat, 14 Mar 2009 01:06:23 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Sean C. Farley" References: <188BDECC-1064-4421-8687-F9759E25FD1F@freebsd.org> <49BAE99B.2030508@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Rui Paulo Subject: Re: tap(4) SIOCSIFMTU patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 01:06:28 -0000 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