Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)
From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 05/27/04
- Previous message: Yar Tikhiy: "VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- In reply to: Yar Tikhiy: "VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Next in thread: Yar Tikhiy: "Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Reply: Yar Tikhiy: "Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 27 May 2004 08:02:28 -0700 To: Yar Tikhiy <yar@comp.chem.msu.su>
On Thu, May 27, 2004 at 06:10:55PM +0400, Yar Tikhiy wrote:
> [moving the discussion from the cvs lists to -net]
>
> On Wed, May 26, 2004 at 10:41:52AM +0400, Gleb Smirnoff wrote:
> >
> > 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.
> >
> > Two comments:
> >
> > 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.
> >
> > Two deal with second issue some new mechanism should be introduced in netgraph,
> > e.g. "broadcast" messages, which go down a hook spreading across all nodes,
> > and only nodes with appropriate cookie will see this message delivered.
> >
> > 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.
> >
> > From my point of view this is a good idea.
>
> 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.
>
> 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
-- 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
- application/pgp-signature attachment: stored
- Previous message: Yar Tikhiy: "VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- In reply to: Yar Tikhiy: "VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Next in thread: Yar Tikhiy: "Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Reply: Yar Tikhiy: "Re: VLAN_MTU (was Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]