Date: Wed, 13 Oct 2010 17:55:19 +0000 (UTC) From: Pyun YongHyeon <yongari@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/pci if_rl.c Message-ID: <201010131755.o9DHtaAo002939@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
yongari 2010-10-13 17:55:19 UTC
FreeBSD src repository
Modified files:
sys/pci if_rl.c
Log:
SVN rev 213796 on 2010-10-13 17:55:19Z by yongari
Rewrite interrupt handler to give fairness for both RX and TX.
Previously rl(4) continuously checked whether there are RX events
or TX completions in forever loop. This caused TX starvation under
high RX load as well as consuming too much CPU cycles in the
interrupt handler. If interrupt was shared with other devices which
may be always true due to USB devices in these days, rl(4) also
tried to process the interrupt. This means polling(4) was the only
way to mitigate the these issues.
To address these issues, rl(4) now disables interrupts when it
knows the interrupt is ours and limit the number of iteration of
the loop to 16. The interrupt would be enabled again before exiting
interrupt handler if the driver is still running. Because RX buffer
is 64KB in size, the number of iterations in the loop has nothing
to do with number of RX packets being processed. This change
ensures sending TX frames under high RX load.
RX handler drops a driver lock to pass received frames to upper
stack such that there is a window that user can down the interface.
So rl(4) now checks whether driver is still running before serving
RX or TX completion in the loop.
While I'm here, exit interrupt handler when driver initialized
controller.
With this change, now rl(4) can send frames under high RX load even
though the TX performance is still not good(rl(4) controllers can't
queue more than 4 frames at a time so low TX performance was one of
design issue of rl(4) controllers). It's much better than previous
TX starvation and you should not notice RX performance drop with
this change. Controller still shows poor performance under high
network load but for many cases it's now usable without resorting
to polling(4).
MFC after: 2 weeks
Revision Changes Path
1.195 +28 -16 src/sys/pci/if_rl.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010131755.o9DHtaAo002939>