FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F8.2.0 2010-11-16T20:36:52Z 2010-11-16T20:36:52Z Pyun YongHyeon yongari@FreeBSD.org 2010-11-16T20:36:52Z urn:sha1:90c8dfe3940c82c00e368da095e58a988a1eddf1 r215018: Consistently use tab character instead of using space character. No functional changes. r215019: Remove trailing white spaces. r215020: Remove standard PCI configuration space register definitions. 2010-11-16T20:32:09Z Pyun YongHyeon yongari@FreeBSD.org 2010-11-16T20:32:09Z urn:sha1:6713b3e9eef5e447a1104f321e281ba6df969234 Follow the lead of vendor's interrupt moderation mechanism. It seems RTL8169/RTL8168/RTL810xE has a kind of interrupt moderation mechanism but it is not documented at all. The magic value dramatically reduced number of interrupts without noticeable performance drops so apply it to all RTL8169/RTL8169 controllers. Vendor's FreeBSD driver also applies it to RTL810xE controllers but their Linux driver explicitly cleared the register, so do not enable interrupt moderation for RTL810xE controllers. While I'm here sort 8169 specific registers. Obtained from: RealTek FreeBSD driver MFC r215025: Only moderate TX completion interrupts. Relying on taskqueue to suppress RX interrupts seems to give better RX performance than RX interrupt moderation. 2010-11-15T17:48:13Z Maxim Sobolev sobomax@FreeBSD.org 2010-11-15T17:48:13Z urn:sha1:f7662e479fb72e1530331c09b1f1898f9729487f Add new tunable 'net.link.ifqmaxlen' to set default send interface queue length. The default value for this parameter is 50, which is quite low for many of today's uses and the only way to modify this parameter right now is to edit if_var.h file. Also add read-only sysctl with the same name, so that it's possible to retrieve the current value. 2010-11-13T01:09:44Z Pyun YongHyeon yongari@FreeBSD.org 2010-11-13T01:09:44Z urn:sha1:322cc187532b7d79c752a62148098d71c9c39987 Add simple MAC statistics counter reading support. Unfortunately useful counters like rl_missed_pkts is 16 bits quantity which is too small to hold meaningful information happened in a second. This means driver should frequently read these counters in order not to lose accuracy and that approach is too inefficient in driver's view. Moreover it seems there is no way to trigger an interrupt to detect counter near-full or wraparound event as well as lacking clearing the MAC counters. Another limitation of reading the counters from RealTek controllers is lack of interrupt firing at the end of DMA cycle of MAC counter read request such that driver have to poll the end of the DMA which is a time consuming process as well as inefficient. The more severe issue of the MAC counter read request is it takes too long to complete the DMA. All these limitation made maintaining MAC counters in driver impractical. For now, just provide simple sysctl interface to trigger reading the MAC counters. These counters could be used to track down driver issues. Users can read MAC counters maintained in controller with the following command. #sysctl dev.re.0.stats=1 While I'm here add check for validity of dma map and allocated memory before unloading/freeing them. Tested by: rmacklem 2010-11-07T11:12:29Z Marius Strobl marius@FreeBSD.org 2010-11-07T11:12:29Z urn:sha1:605d4f8b84e727c542eec73fceec034384cb7d5e Convert the PHY drivers to honor the mii_flags passed down and convert the NIC drivers as well as the PHY drivers to take advantage of the mii_attach() introduced in r213878 (MFC'ed to stable/8 in r214684) to get rid of certain hacks. For the most part these were: - Artificially limiting miibus_{read,write}reg methods to certain PHY addresses; we now let mii_attach() only probe the PHY at the desired address(es) instead. - PHY drivers setting MIIF_* flags based on the NIC driver they hang off from, partly even based on grabbing and using the softc of the parent; we now pass these flags down from the NIC to the PHY drivers via mii_attach(). This got us rid of all such hacks except those of brgphy() in combination with bce(4) and bge(4), which is way beyond what can be expressed with simple flags. While at it, I took the opportunity to change the NIC drivers to pass up the error returned by mii_attach() (previously by mii_phy_probe()) and unify the error message used in this case where and as appropriate as mii_attach() actually can fail for a number of reasons, not just because of no PHY(s) being present at the expected address(es). Reviewed by: jhb, yongari 2010-10-27T02:04:24Z Pyun YongHyeon yongari@FreeBSD.org 2010-10-27T02:04:24Z urn:sha1:8d68060ac6cb5402c2d154f42e1aa878b7dc48eb 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). 2010-10-08T18:19:05Z Pyun YongHyeon yongari@FreeBSD.org 2010-10-08T18:19:05Z urn:sha1:1447383886e649bcd7f2d3cf6711965ea570b0ee Rename rl_setmulti() to rl_rxfilter() as rl_rxfilter() will handle IFF_ALLMULTI/IFF_PROMISC as well as multicast filter configuration. Rewrite RX filter logic to reduce number of register accesses and make it handle promiscuous/allmulti toggling without controller reinitialization. Previously rl(4) counted on controller reinitialization to reprogram promiscuous configuration but r211767 resulted in avoiding controller reinitialization whenever promiscuous mode is toggled. To address this, keep track of driver's view of interface state and handle IFF_ALLMULTI/IFF_PROMISC changes without reinitializing controller. This should fix a regression introduced in r211267. While I'm here remove unnecessary variable reassignment in ioctl handler. PR: kern/151079 2010-09-24T19:27:47Z Pyun YongHyeon yongari@FreeBSD.org 2010-09-24T19:27:47Z urn:sha1:c6f916d0ee7bfc4c011e27b01505695a8f274e7b Remove unnecessary controller reinitialization. PR: kern/87506 2010-08-31T00:15:20Z Pyun YongHyeon yongari@FreeBSD.org 2010-08-31T00:15:20Z urn:sha1:d27a6b0e24529c7f9afc3ab41512f77877eb878c It seems some newer RTL8139 controllers provides only memory space register mapping. I'm not sure whether it comes from the fact that controllers live behind certain PCI brdge(PLX PCI 6152 33BC) and the bridge has some issues in handling I/O space register mapping. Unfortunately it's not possible to narrow down to an exact controller that shows this issue because RealTek used the same PCI device/revision id again. In theory, it's possible to check parent PCI bridge device and change rl(4) to use memory space register mapping if the parent PCI bridge is PLX PCI 6152. But I didn't try to do that and we wouldn't get much benefit with added complexity. Blindly switching to use memory space register mapping for rl(4) may make most old controllers not to work. At least, I don't want to take potential risk from such change. So use I/O space register mapping by default but give users chance to override it via a tunable. The tunable to use memory space register mapping would be given by adding the following line to /boot/loader.conf file. dev.rl.%d.prefer_iomap="0" This change makes P811B quad-port work with this tunable. 2010-08-15T23:11:38Z Pyun YongHyeon yongari@FreeBSD.org 2010-08-15T23:11:38Z urn:sha1:4612d3594884b832991b4b6bbe1936d083fae4bc Implement WOL. WOL is supported on RTL8139B or newer controllers. PR: kern/148013