Date: Wed, 9 Jul 2008 13:14:19 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: John Baldwin <jhb@freebsd.org>, net@freebsd.org Subject: Re: svn commit: r180256 - head/sys/dev/arl Message-ID: <20080709131101.S8639@fledge.watson.org> In-Reply-To: <20080705161831.F13262@delplex.bde.org> References: <200807041748.m64HmZur018637@svn.freebsd.org> <20080705161831.F13262@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080709131101.S8639>