Date: Thu, 3 Feb 2000 13:47:08 -0500 (EST) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: "Matthew N. Dodd" <winter@jurai.net> Cc: "Pedro J. Lobo" <pjlobo@euitt.upm.es>, freebsd-net@FreeBSD.ORG Subject: Re: 802.1Q VLANs Message-ID: <200002031847.NAA62013@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.BSF.4.21.0002031236160.479-100000@sasami.jurai.net> References: <Pine.OSF.4.21.0002031711230.1338-100000@haddock.euitt.upm.es> <Pine.BSF.4.21.0002031236160.479-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 3 Feb 2000 12:40:47 -0500 (EST), "Matthew N. Dodd" <winter@jurai.net> said: > Humm... Ideally the VLAN driver should be able to set the MTU for its > parent and deal with being able to set the MTU > 1500. No, you've got it the wrong way 'round. If the interface driver is written to be able to accept 1500-byte frames with an 18-byte header (as opposed to the ``normal'' 14-byte header), it needs to inform the upper layers of this by setting its advertised header length (ifi_hdrlen) to 18 rather than 14. The driver should always do this, if the hardware is capable, so that those frames will be made available to bpf. > Well, I see no reason to restrict people to cards that don't support large > frames; if they really need to use VLANs they can adjust the MTU down. In > the real world MTU discovery will insure that they aren't too big of a > problem. No, it won't. In the real world, MTU discovery will never be invoked, because switches do not allow users to reconfigure the MTU. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002031847.NAA62013>