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

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [OT] ALSA userspace API complexity
    ... can plug to this all device drivers. ... so "necessary features" roughly equals the union of all ... please have a look at, say, the rme hammerfall cards, compare them with ye olde sblive, then take a look at usb audio devices and for dessert, take a peek into current firewire hardware. ... jaroslav, takashi and the other alsa developers have been toiling with this for years, and i hate to see them having to take shit from people who don't do anything more with their sound hardware than listen to mp3s in stereo and can't imagine anything else. ...
    (Linux-Kernel)
  • Re: Java app spuriously opening ports
    ... At the very least there needs to be a way to put device drivers off ... all I/O cards. ... Uplevelling the hardware interface would work by allowing ... even a keyboard utility or driver can snoop and report ...
    (comp.lang.java.programmer)
  • Re: Accessing memory at 0xb800
    ... > class on OS and hardware, and I think it's the video card who simply ... These are all various terminal device drivers. ... Notice how we get hardware access in our program without any need for ... allows resource sharing, ease of writing portable code, simpler code, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Accessing memory at 0xb800
    ... > class on OS and hardware, and I think it's the video card who simply ... These are all various terminal device drivers. ... Notice how we get hardware access in our program without any need for ... allows resource sharing, ease of writing portable code, simpler code, ...
    (comp.lang.cpp)
  • Re: TX Multiqueue?
    ... The rx hardware queue is determined by the hardware. ... of a crc32 of the 4-tuple in cxgb. ... of this is moving the queues into the driver. ...
    (freebsd-current)