From owner-freebsd-net@FreeBSD.ORG Wed Jul 9 12:14:20 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85CE31065671 for ; Wed, 9 Jul 2008 12:14:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7438FC1E for ; Wed, 9 Jul 2008 12:14:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9C59946C4B; Wed, 9 Jul 2008 08:14:19 -0400 (EDT) Date: Wed, 9 Jul 2008 13:14:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20080705161831.F13262@delplex.bde.org> Message-ID: <20080709131101.S8639@fledge.watson.org> References: <200807041748.m64HmZur018637@svn.freebsd.org> <20080705161831.F13262@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John Baldwin , net@freebsd.org Subject: Re: svn commit: r180256 - head/sys/dev/arl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2008 12:14:20 -0000 On Sat, 5 Jul 2008, Bruce Evans wrote: > On Fri, 4 Jul 2008, John Baldwin wrote: Since ifqmaxlen isn't a tuneable or > sysctl, and is statically initialized to IFQ_MAXLEN, not using only makes a > difference if someone iniitalizes it diffently using a debugger, so these > bugs are normally just spelling errors. IFQ_MAXLEN is also too small for > 1Gbps or even 100Nbps hardware devices, so only drivers for old hardware and > some software drivers can use it anyway. I was actually thinking about this this morning -- Paul Saab pointed out to me that, on Linux, you can run-time tune the transmit queue limit using ifconfig(8). I think doing something similar would, if nothing else, make it easier to understand the impact of our current queue settings in testing. And, just to put it on the table in e-mail, since I know it has come up a lot at developer summits: the ALTQ infrastructure is decreasingly compatible with current network devices, which often have quite large queues (descriptor rings) in hardware, or where there are multiple transmit queues. One possibility I've been considering is making the whole ifq subsystem a library to device drivers, rather than a required interface to transmit. This would allow the device driver to instantiate more than one if there are multiple hardware queues that need to be represented, or, for example, allow synthetic encapsulation interfaces (such as vlan) to avoid queueing entirely and directly dispatch to the lower layer interface without requiring a mandatory enqueue/dequeue step. I've started hacking on this every now and then, but it requires a lot of code to be touched -- it's something we do need to address before 8.0, however. Robert N M Watson Computer Laboratory University of Cambridge