On Tue, Nov 06, 2012 at 10:46:28AM +0000, Poul-Henning Kamp wrote: > -------- > In message <5098e8b4.5040...@freebsd.org>, Andre Oppermann writes: > > >> I think it should go away, and if there still is a relevant > >> usage segment, be replaced by _real_ "device-polling" which is > >> not tied to the network stack. > > > >Don't we already have the equivalent with a fast interrupt thread > >that simply acknowledges and disables the interrupt [...] > > The point is that not all hardware have interrupt-pacing, so > being able to poll at a lower rate in software would save overhead. > > I'm not sure if the hardware where this applies is still relevant, > it would probably be mostly in the embedded space.
I've used polling on embedded systems to avoid userland starvation and not to gain bandwidth. Interrupts have priority over userland processes and with a CPU not capable to handle say 100MBit/s ethernet interrupt load you can't even login via console console. With polling such a machine is way more responsive and allow people to find out that there is a saturated link before pulling the plug. There are likely other solutions, but it worked well for that puprose. -- B.Walter <be...@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
