On Tue, Nov 06, 2012 at 10:46:28AM +0000, Poul-Henning Kamp wrote: > -------- > In message <5098E8B4.5040309_at_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 <bernd_at_bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.Received on Sun Nov 11 2012 - 10:16:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC