From owner-freebsd-net@FreeBSD.ORG  Thu May 27 08:05:25 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id A213F16A4CF
	for <net@freebsd.org>; Thu, 27 May 2004 08:05:25 -0700 (PDT)
Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 563F943D49
	for <net@freebsd.org>; Thu, 27 May 2004 08:05:17 -0700 (PDT)
	(envelope-from brdavis@odin.ac.hmc.edu)
Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain
	[127.0.0.1])
	by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i4RF2SSK032075;
	Thu, 27 May 2004 08:02:28 -0700
Received: (from brdavis@localhost)
	by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i4RF2S3n032074;
	Thu, 27 May 2004 08:02:28 -0700
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>
Message-ID: <20040527150228.GB30789@Odin.AC.HMC.Edu>
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>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y"
Content-Disposition: inline
In-Reply-To: <20040527141055.GA32704@comp.chem.msu.su>
User-Agent: Mutt/1.5.4i
cc: net@freebsd.org
Subject: Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c
	if_fxpvar.h)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 15:05:25 -0000


--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--