summaryrefslogtreecommitdiffstats
path: root/sys/dev/re
Commit message (Collapse)AuthorAgeFilesLines
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls tojhb2011-03-231-4/+4
| | | | pci_find_cap() instead.
* Add initial support for RTL8401E PCIe Fast Ethernet.yongari2011-02-161-1/+6
| | | | PR: 154789
* Disable TX IP checksum offloading for RTL8168C controllers. Theyongari2011-02-041-4/+19
| | | | | | | | | | | | | | | | controller in question generates frames with bad IP checksum value if packets contain IP options. For instance, packets generated by ping(8) with record route option have wrong IP checksum value. The controller correctly computes checksum for normal TCP/UDP packets though. There are two known RTL8168/8111C variants in market and the issue I observed happened on RL_HWREV_8168C_SPIN2. I'm not sure RL_HWREV_8168C also has the same issue but it would be better to assume it has the same issue since they shall share same core. RTL8102E which is supposed to be released at the time of RTL8168/8111C announcement does not have the issue. Tested by: Konstantin V. Krotov ( kkv <> insysnet dot ru )
* Add support for RTL8105E PCIe Fast Ethernet controller. It seemsyongari2011-01-261-1/+7
| | | | | | | | | | | | | | the controller has a kind of embedded controller/memory and vendor applies a large set of magic code via undocumented PHY registers in device initialization stage. I guess it's a firmware image for the embedded controller in RTL8105E since the code is too big compared to other DSP fixups. However I have no idea what that magic code does and what's purpose of the embedded controller. Fortunately driver seems to still work without loading the firmware. While I'm here change device description of RTL810xE controller. H/W donated by: Realtek Semiconductor Corp.
* Do not use interrupt taskqueue on controllers with MSI/MSI-Xyongari2011-01-261-32/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | capability. One of reason using interrupt taskqueue in re(4) was to reduce number of TX/RX interrupts under load because re(4) controllers have no good TX/RX interrupt moderation mechanism. Basic TX interrupt moderation is done by hardware for most controllers but RX interrupt moderation through undocumented register showed poor RX performance so it was disabled in r215025. Using taskqueue to handle RX interrupt greatly reduced number of interrupts but re(4) consumed all available CPU cycles to run the taskqueue under high TX/RX network load. This can happen even with RTL810x fast ethernet controller and I believe this is not acceptable for most systems. To mitigate the issue, use one-shot timer register to moderate RX interrupts. The timer register provides programmable one-shot timer and can be used to suppress interrupt generation. The timer runs at 125MHZ on PCIe controllers so the minimum time allowed for the timer is 8ns. Data sheet says the register is 32 bits but experimentation shows only lower 13 bits are valid so maximum time that can be programmed is 65.528us. This yields theoretical maximum number of RX interrupts that could be generated per second is about 15260. Combined with TX completion interrupts re(4) shall generate less than 20k interrupts. This number is still slightly high compared to other intelligent ethernet controllers but system is very responsive even under high network load. Introduce sysctl variable dev.re.%d.int_rx_mod that controls amount of time to delay RX interrupt processing in units of us. Value 0 completely disables RX interrupt moderation. To provide old behavior for controllers that have MSI/MSI-X capability, introduce a new tunable hw.re.intr_filter. If the tunable is set to non-zero value, driver will use interrupt taskqueue. The default value of the tunable is 0. This tunable has no effect on controllers that has no MSI/MSI-X capability or if MSI/MSI-X is explicitly disabled by administrator. While I'm here cleanup interrupt setup/teardown since re(4) uses single MSI/MSI-X message at this moment.
* Remove TX taskqueue and directly invoke re_start in interrupt task.yongari2011-01-251-20/+13
|
* Prefer MSI-X to MSI on controllers that support MSI-X. Allyongari2011-01-251-11/+52
| | | | | | | recent PCIe controllers(RTL8102E or later and RTL8168/8111C or later) supports either 2 or 4 MSI-X messages. Unfortunately vendor did not publicly release RSS related information yet. However switching to MSI-X is one-step forward to support RSS.
* Disable TSO for all Realtek controllers. Experimentation showedyongari2011-01-251-7/+5
| | | | | | | | RTL8111C generated corrupted frames where TCP option header was broken. All other sample controllers I have did not show such problem so it could be RTL8111C specific issue. Because there are too many variants it's hard to tell how many controllers have such issue. Just disable TSO by default but have user override it.
* Apply TX interrupt moderation to all RTL810xE PCIe Fast Ethernetyongari2011-01-241-14/+2
| | | | | | | | controllers. Experimentation with RTL8102E, RTL8103E and RTL8105E showed dramatic decrement of TX completion interrupts under high TX load(e.g. from 147k interrupts/second to 10k interrupts/second) With this change, TX interrupt moderation is applied to all controllers except RTL8139C+.
* Change model names of controller RTL_HWREV_8168_SPIN[123] to real ones.yongari2011-01-181-6/+6
| | | | | | | s/RL_HWREV_8168_SPIN1/RL_HWREV_8168B_SPIN1/g s/RL_HWREV_8168_SPIN2/RL_HWREV_8168B_SPIN2/g s/RL_HWREV_8168_SPIN3/RL_HWREV_8168B_SPIN3/g No functional changes.
* Implement initial jumbo frame support for RTL8168/8111 C/D/E PCIeyongari2011-01-171-111/+347
| | | | | | | | | | | | | | | | | | | | | | | | GbE controllers. It seems these controllers no longer support multi-fragmented RX buffers such that driver have to allocate physically contiguous buffers. o Retire RL_FLAG_NOJUMBO flag and introduce RL_FLAG_JUMBOV2 to mark controllers that use new jumbo frame scheme. o Configure PCIe max read request size to 4096 for standard frames and reduce it to 512 for jumbo frames. o TSO/checksum offloading is not supported for jumbo frames on these controllers. Reflect it to ioctl handler and driver initialization. o Remove unused rl_stats_no_timeout in softc. o Embed a pointer to structure rl_hwrev into softc to keep track of controller MTU limitation and remove rl_hwrev in softc since that information is available through a pointer to structure rl_hwrev. Special thanks to Realtek for donating sample hardwares which made this possible. H/W donated by: Realtek Semiconductor Corp.
* Add initial support for RTL8168E/8111E-VL PCIe GbE.yongari2011-01-171-0/+6
| | | | H/W donated by: Realtek Semiconductor Corp.
* If driver is not able to allocate RX buffer, do not start driver.yongari2011-01-131-6/+10
| | | | | | While I'm here move RX buffer allocation and descriptor initialization up to not touch hardware registers in case of RX buffer allocation failure.
* Make sure to check validity of dma maps before destroying.yongari2011-01-131-6/+10
|
* re_reset() should be called only after setting device specificyongari2011-01-131-5/+5
| | | | features.
* Allow TX/RX checksum offloading to be configured independently.yongari2011-01-131-3/+9
|
* For re(4) controllers that uses new jumbo frame scheme(RTL8168C/D/E),yongari2011-01-121-2/+7
| | | | | | | | | | | | | | | | | | | limit maximum RX buffer size to RE_RX_DESC_BUFLEN instead of blindly configuring it to 16KB. Due to lack of documentation, re(4) didn't allow jumbo frame on these controllers. However it seems controller is confused with jumbo frame such that it can DMA the received frame to wrong address instead of splitting it into multiple RX buffers. Of course, this caused panic. Since re(4) does not support jumbo frames on these controllers, make controller drop frame that is longer than RE_RX_DESC_BUFLEN sized frame. Fortunately RTL810x controllers, which do not support jumbo frame, have no such issues but this change also limited maximum RX buffer size allowed to RTL810x controllers. Allowing 16KB RX buffer for controllers that have no such capability is meaningless. MFC after: 3 days
* When driver is not running, do not send DUMP command to controlleryongari2011-01-101-0/+5
| | | | | | and just show old (cached) values. Controller will not respond to the command unless MAC is enabled so DUMP request for down interface caused request timeout.
* Implement TSO on RealTek RTL8168/8111 C or later controllers.yongari2011-01-101-21/+19
| | | | | | | | | | | | RealTek changed TX descriptor format for later controllers so these controllers require MSS configuration in different location of TX descriptor. TSO is enabled by default for controllers that use new descriptor format. For old controllers, TSO is still disabled by default due to broken frames under certain conditions but users can enable it. Special thanks to Hayes Wang at RealTek. MFC after: 2 weeks
* Add flow control for all re(4) controllers. re(4) controllers doyongari2010-11-151-1/+1
| | | | | | | not provide any MAC configuration interface for resolved flow control parameters. There is even no register that configures water mark which will control generation of pause frames. However enabling flow control surely enhanced performance a lot.
* Only moderate TX completion interrupts. Relying on taskqueue toyongari2010-11-091-1/+1
| | | | | suppress RX interrupts seems to give better RX performance than RX interrupt moderation.
* Follow the lead of vendor's interrupt moderation mechanism.yongari2010-11-081-0/+18
| | | | | | | | | | | | | | 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
* Reduce spin wait time consumed in GMII register access routine.yongari2010-11-081-4/+12
| | | | | | | | | | | | There were a couple of attempts in the past to reduce it since it took more than 1ms. Because mii_tick() periodically polls link status, waiting more than 1ms for each GMII register access was overkill. Unfortunately all previous attempts were failed with various ways on different controllers. This time, add additional 20us dealy at the end of GMII register access which seems to requirement of all RealTek controllers to issue next GMII register access request. This is the same way what Linux does.
* Add simple MAC statistics counter reading support. Unfortunatelyyongari2010-11-051-15/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* style(9).yongari2010-11-051-3/+3
|
* Remove extra white spaces.yongari2010-11-051-3/+3
|
* Enable 64bit DMA addressing for RTL810xE/RTL8168/RTL8111 PCIeyongari2010-11-051-2/+6
| | | | | | controllers. Some old PCI controllers may work with DAC but it was known to be buggy so 64bit DMA addressing is used only on PCIe controllers.
* Convert the PHY drivers to honor the mii_flags passed down and convertmarius2010-10-151-17/+11
| | | | | | | | | | | | | | | | | | | | | | | the NIC drivers as well as the PHY drivers to take advantage of the mii_attach() introduced in r213878 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
* Don't change PCIe maximum read request size to 2048 on RTL810xyongari2010-05-071-3/+5
| | | | | | | | controllers. It caused device timeouts. Reported by: McLone < mclone <> gmail dot com > Tested by: McLone < mclone <> gmail dot com > MFC after: 5 days
* Add preliminary support for 8168E/8111E PCIe controller.yongari2010-04-091-2/+12
| | | | | | | While I'm here simplify device description string. Tested by: Michael Beckmann < michael <> apfel dot de > MFC after: 5 days
* Add TSO on VLANs. Because re(4) has a TSO limitation for jumboyongari2010-02-221-9/+17
| | | | | | | | frame, make sure to update VLAN capabilities whenever jumbo frame is configured. While I'm here rearrange interface capabilities configuration. The controller requires VLAN hardware tagging to make TSO work on VLANs so explicitly check this requirement.
* Increase PCIe maximuim read request size to 2048. Because re(4) usesyongari2010-02-211-0/+3
| | | | | | | | Tx DMA burst size 2048, I beleive PCIe maximum read request size also should match to the value of Tx DMA burst size. With this change I can get more than 800Mbps for TCP bulk transfers. Previously I was not able to get more than 700Mbps. If I enable TSO it now shows 927Mbps.
* Add initial support for RTL8103E PCIe fastethernet.yongari2010-01-271-1/+8
| | | | PR: kern/142974
* Move interface reinitialization down after disabling WOL in resumeyongari2009-11-191-4/+5
| | | | path.
* Minimize interface reinitialization by checking IFF_DRV_RUNNINGyongari2009-11-191-4/+16
| | | | | | | flag. This fixes unnecessary interface UP/DOWNs during getting an IP address via DHCP. Tested by: Warren Block ( wblock<> wonkity dot com )
* Add a check to know whether driver is still running afteryongari2009-11-021-0/+2
| | | | | | | | | | | | | reacquiring driver lock in Rx handler. re(4) drops a driver lock before passing received frame to upper stack and reacquire the lock. During the time window ioctl calls could be executed and if the ioctl was interface down request, driver will stop the controller and free allocated mbufs. After that when driver comes back to Rx handler again it does not know what was happend so it could access free mbufs which in turn cause panic. Reported by: Norbert Papke < npapk <> acm dot org > Tested by: Norbert Papke < npapk <> acm dot org >
* Add RTL8168DP/RTL8111DP device id. While I'm here append "8111D" toyongari2009-08-241-3/+5
| | | | | | | | the description of RTL8168D as RL_HWREV_8168D can be either RTL8168D or RTL8111D. PR: kern/137672 MFC after: 3 days
* Adding hardware ID for RTL810x PCIe found on HP Pavilion DV2-1022AX.avatar2009-07-141-0/+2
| | | | | Reviewed by: yongari Approved by: re (kib, kensmith)
* Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/rwatson2009-06-261-2/+2
| | | | | | | | | | | | | IF_ADDR_UNLOCK() across network device drivers when accessing the per-interface multicast address list, if_multiaddrs. This will allow us to change the locking strategy without affecting our driver programming interface or binary interface. For two wireless drivers, remove unnecessary locking, since they don't actually access the multicast address list. Approved by: re (kib) MFC after: 6 weeks
* When user_frac in the polling subsystem is low it is going to busy theattilio2009-05-301-12/+19
| | | | | | | | | | | | | | | | | | | | | CPU for too long period than necessary. Additively, interfaces are kept polled (in the tick) even if no more packets are available. In order to avoid such situations a new generic mechanism can be implemented in proactive way, keeping track of the time spent on any packet and fragmenting the time for any tick, stopping the processing as soon as possible. In order to implement such mechanism, the polling handler needs to change, returning the number of packets processed. While the intended logic is not part of this patch, the polling KPI is broken by this commit, adding an int return value and the new flag IFCAP_POLLING_NOCOUNT (which will signal that the return value is meaningless for the installed handler and checking should be skipped). Bump __FreeBSD_version in order to signal such situation. Reviewed by: emaste Sponsored by: Sandvine Incorporated
* For RTL8139C+ controllers, have controller handle padding shortyongari2009-04-201-4/+6
| | | | | | | | | | | | | checksum offload frames. Software workaround used for broken controllers(RTL8169, RTL8168, RTL8168B) seem to cause watchdog timeouts on RTL8139C+. Introduce a new flag RL_FLAG_AUTOPAD to mark automatic padding feature of controller and set it for RTL8139C+ and controllers that use new descriptor format. This fixes watchdog timeouts seen on RTL8139C+. Reported by: Dimitri Rodis < DimitriR <> integritasystems dot com > Tested by: Dimitri Rodis < DimitriR <> integritasystems dot com >
* Partial revert r185756.yongari2009-03-311-0/+2
| | | | | | | | | | It seems that RTL8168D and RTL8102EL requires additional settle time to complete RL_PHYAR register write. Accessing RL_PHYAR register right after the write causes errors for subsequent PHY register accesses. Tested by: george at luckytele dot com, Steve Wills < STEVE at stevenwills dot com >
* remove now-redunant cardbus attachment lines.imp2009-03-091-1/+0
|
* Add a new tunable hw.re.prefer_iomap which disables memory registeryongari2009-03-091-13/+25
| | | | | | | | | mapping. The tunable is OFF for all controllers except RTL8169SC family. RTL8169SC seems to require more magic to use memory register mapping. r187483 added a fix for RTL8169SCe controller but it does not looke like fix other variants of RTL8169SC. Tested by: Gavin Stone-Tolcher g.stone-tolcher <> its dot uq dot edu dot au
* Allocating 2 MSI messages do not seem to work on certain controllersyongari2009-02-111-1/+2
| | | | | | | so use just 1 MSI message. This fixes regression introduced in r188381. Tested by: many
* Reclaim transmitted frames in re_tick(). This is for PCIeyongari2009-02-091-1/+8
| | | | | | controllers that lose Tx completion interrupts under certain conditions. With this change it's safe to use MSI on PCIe controllers so enable MSI on these controllers.
* - Add support for 8110SCe part. Some magic registers were taken fromjkim2009-01-201-19/+39
| | | | | | | Linux driver. - Swap hardware revisions for 8110S and 8169S as Linux driver claims. Reviewed by: yongari (early version)
* Retire RL_FLAG_INVMAR bit to match its comment and reality.jkim2009-01-201-11/+9
|
* - Do not read and write RX configuration register multiple times.jkim2009-01-201-66/+31
| | | | | | | | | - Always program RX configuration register from scratch instead of doing read/modify/write. - Rename re_setmulti() to re_set_rxmode() to be reflect reality. - Simplify hash filter logic a little while I am here. Reviewed by: yongari (early version)
* Sometimes RTL8168B seems to take long time to access GMII registersyongari2009-01-191-4/+4
| | | | | | | | in device attach phase. Double GMII register access timeout value to fix the issue. Reported by: wkoszek Tested by: wkoszek
OpenPOWER on IntegriCloud