MFC r213796:

MFC r213796:
  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).

git-svn-id: svn://svn.freebsd.org/base/stable/8@214407 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f