Date: Wed, 26 May 2004 07:20:55 +0400 From: Yar Tikhiy <yar@freebsd.org> To: Ruslan Ermilov <ru@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20040526032055.GA42697@comp.chem.msu.su> In-Reply-To: <20040525184757.GA5546@ip.net.ua> References: <200405251449.i4PEnkIa098672@repoman.freebsd.org> <20040525164251.GA3245@ip.net.ua> <20040525173458.GA18554@comp.chem.msu.su> <20040525184757.GA5546@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 25, 2004 at 09:47:57PM +0300, Ruslan Ermilov wrote: > On Tue, May 25, 2004 at 09:34:59PM +0400, Yar Tikhiy wrote: > > On Tue, May 25, 2004 at 07:42:51PM +0300, Ruslan Ermilov wrote: > > > On Tue, May 25, 2004 at 07:49:46AM -0700, Yar Tikhiy wrote: > > > > yar 2004/05/25 07:49:46 PDT > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/dev/fxp if_fxp.c if_fxpvar.h > > > > Log: > > > > Teach fxp(4) to control VLAN_MTU in the hardware. > > > > Now reception of extended frames can be toggled > > > > through ioctl(SIOCSIFCAP). > > > > > > > > The card will also receive extended frames when > > > > in promiscuous mode. > > > > > > > > Revision Changes Path > > > > 1.209 +16 -8 src/sys/dev/fxp/if_fxp.c > > > > 1.30 +1 -0 src/sys/dev/fxp/if_fxpvar.h > > > > > > > This change also made VLAN_MTU disabled by default, what was > > > the reason to do it? > > > > I disabled it so that the interface won't violate without need > > the Ethernet standard WRT the upper limit on frame size. > > > What clause and in which of many 802 standards do you refer to? I refer to 802.3. AFAIK it hasn't been a long time since it relaxed the limit to allow for VLAN-tagged frames (search for maxUntaggedFrameSize.) And a lot of implementations still stick to the older 1518-byte limit. > > vlan(4) will enable VLAN_MTU on an fxp interace as soon as a vlan > > interface is attached to it. > > > vlan(4) may not be the only consumer of VLAN capable frames. > For example, I have ng_vlan(4) connected to ng_ether(4) node, > and doing VLAN processing here, and this change will break > the existing and working config. I can survive, but it sounds > against POLA to me. IMHO ng_vlan(4) is young enough to implement VLAN_MTU control instead of relying on the old behaviour of VLAN_MTU, which resulted from bugs I've been fixing recently. ng_vlan(4) could send a control command to ng_ether(4) instructing the latter to increment the VLAN counter on the Ethernet interface and toggle VLAN_MTU on if the counter value became equal to 1. Another way I see is to drop automatic fiddling with VLAN_MTU in the first place and implement an option for ifconfig(8) so that a user/admin can control the capability WRT a particular case, e.g., disable it if a NIC displays erroneous behaviour in long frame mode. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040526032055.GA42697>