Date: Thu, 27 May 2004 08:02:28 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: net@freebsd.org Subject: Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h) Message-ID: <20040527150228.GB30789@Odin.AC.HMC.Edu> In-Reply-To: <20040527141055.GA32704@comp.chem.msu.su> References: <200405251449.i4PEnkIa098672@repoman.freebsd.org> <20040525164251.GA3245@ip.net.ua> <20040525173458.GA18554@comp.chem.msu.su> <20040525184757.GA5546@ip.net.ua> <20040526032055.GA42697@comp.chem.msu.su> <20040526064152.GD24738@cell.sick.ru> <20040527141055.GA32704@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
--xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 27, 2004 at 06:10:55PM +0400, Yar Tikhiy wrote: > [moving the discussion from the cvs lists to -net] >=20 > On Wed, May 26, 2004 at 10:41:52AM +0400, Gleb Smirnoff wrote: > >=20 > > Y> ng_vlan(4) could send a control command to ng_ether(4) instructing > > Y> the latter to increment the VLAN counter on the Ethernet interface > > Y> and toggle VLAN_MTU on if the counter value became equal to 1. > >=20 > > Two comments: > >=20 > > 1) Just note that it should increment VLAN counter on creating of > > any new VLAN hook. > > 2) There may be some itermediate nodes between ng_ether and ng_vlan, > > e.g. ng_tee(4), ng_etf(4), any custom traffic shaping or accounting > > node. > >=20 > > Two deal with second issue some new mechanism should be introduced in n= etgraph, > > e.g. "broadcast" messages, which go down a hook spreading across all no= des, > > and only nodes with appropriate cookie will see this message delivered. > >=20 > > Y> Another way I see is to drop automatic fiddling with VLAN_MTU in > > Y> the first place and implement an option for ifconfig(8) so that a > > Y> user/admin can control the capability WRT a particular case, e.g., > > Y> disable it if a NIC displays erroneous behaviour in long frame mode. > >=20 > > From my point of view this is a good idea. >=20 > The longer I've been thinking of the issue, the more I'm inclined > to take the latter path. I believe that it would conform to the > good tradition of Unix to offer a user as much control as possible > and avoid doing "automagic" tricks behind user's back. >=20 > Therefore I'd like to ask the community: Would anybody mind if > vlan(4) gave up playing with VLAN_MTU on parent interfaces > while a new option to ifconfig(8), say `vlanmtu', was introduced > so that a user could control the feature manually? This seems OK as long as you enabled VLAN_MTU by default as I see you have just done with fxp. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAtgMDXY6L6fI4GtQRAtE4AJ9FIZ3b9KRu6MVMUxClIUSz2QIYRACfRx/B HEkbgd08BuCxTmMMZWjjRhg= =VNbK -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040527150228.GB30789>