svn commit: r180256 - head/sys/dev/arl

[Robert Watson]

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