From owner-cvs-all@FreeBSD.ORG Tue May 25 20:21:01 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E93AC16A4CE; Tue, 25 May 2004 20:21:01 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD69A43D4C; Tue, 25 May 2004 20:21:00 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i4Q3Ku3F043973; Wed, 26 May 2004 07:20:56 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i4Q3KtYh043972; Wed, 26 May 2004 07:20:55 +0400 (MSD) (envelope-from yar) Date: Wed, 26 May 2004 07:20:55 +0400 From: Yar Tikhiy To: Ruslan Ermilov Message-ID: <20040526032055.GA42697@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040525184757.GA5546@ip.net.ua> User-Agent: Mutt/1.5.6i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2004 03:21:02 -0000 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