From owner-freebsd-stable@FreeBSD.ORG Wed Jan 5 20:50:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1C316A4CF for ; Wed, 5 Jan 2005 20:50:23 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B8443D31 for ; Wed, 5 Jan 2005 20:50:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j05Kpulu017567; Wed, 5 Jan 2005 12:51:56 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j05KpuGP017566; Wed, 5 Jan 2005 12:51:56 -0800 Date: Wed, 5 Jan 2005 12:51:56 -0800 From: Brooks Davis To: jon@abccomm.com Message-ID: <20050105205156.GB16655@odin.ac.hmc.edu> References: <8eea040805010512321bf5b953@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eea040805010512321bf5b953@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-stable@freebsd.org Subject: Re: ALTQ patch for if_vlan.c X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 20:50:23 -0000 On Wed, Jan 05, 2005 at 12:32:55PM -0800, Jon Simola wrote: > I just whipped up this against > 5.3-STABLE #1: Wed Dec 22 17:11:02 PST 2004 > > Would someone who knows a bit more about this than myself give it a > quick lookover and see if it appears sane? I'm mostly wondering about > the splimp() and splx() and whether it's required or excessive due to > the mtx_lock/unlock in the VLAN_LOCK/UNLOCK macros. > > Due to a lack of equipment it's difficult for me to run a seperate > test environment, so any sort of review would be appreciated. ALTQ makes no sense of virtual interfaces. ALTQ works by providing fine-grained control of the dequeueing of packets on to the wire. It's too early to do this when you're still in the virtual interface. You can tag packets appropiratly at this point, but the actual ALTQ queue needs to be on a physical interface. See this thread on adding ALTQ to gif(4): http://www.mail-archive.com/freebsd-net@freebsd.org/msg13875.html FYI, spl*() funtions are all no-ops now. We just have them around to remind us that we need to lock certain functions and to document what was protected before. -- Brooks