CVS log for src/sys/dev/netif/re/if_revar.h

Up to [DragonFly] / src / sys / dev / netif / re

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

- Move RX filter configuration from re_init() into re_setmulti()
- IFF_BROADCAST will never be set/cleared
- Fix SIOCSIFFLAGS support; it was really annoying that each time when I ran
  tcpdump, the NIC reinitialized itself.

- In re_stop(), call re_reset(), which is supposed to stop TX/RX engines.
- In re_reset(), don't touch 0x82 (a magic CSR), which seems to be 8110/8169
  specific.  Write 1 to it on attach path.
  According-to: RealTek r8169-6.007.00
- For certain chips (looks like all MAC2 chips), RE_CMD_RESET will not stop
  TX/RX engines, a seperate command (RE_CMD_STOPREQ) must be issued before
  RE_CMD_RESET.
  According-to: RealTek r8168-8.008.00

- Pack boolean fields into re_softc.re_flags
- Nuke some unused fields in re_softc

# This file should have been committed along with if_re.c rev1.93

- Don't claim 7422 MTU size is support by various 8111/8169 chips (PCI devices);
  6144 MTU size works reliably.
    Set MTU above 6144 (6 * 1024) on these chips and do following test:
    netperf -H host -l 30 -t UDP_STREAM -- -m (mtu-28)
    All kinds of wiredness will pop up on the test box.
- Set max supported MTU to 9216 for 8168D.
  Obtained-from: Realtek r8168-8.008.00
- Set max supported MTU to 6144 for non-8168D GigE chips.
- Cleanup jumbo frame/MTU size related macros.

# As usual, 8169(with 88E1000 PHY) does not seem to work well with any jumbo
# frame size

Correct jumbo frame support for 8168C/CP/D.

These newer chips use ancient design, which does _not_ support gathering RX.
An even worse aspect of the new chips' design is that it does not compat
with old ones: the buffer length field in the RX descriptor seems to be
completely ignored by the hardware.  This means host memory will be trashed
by hardware if driver uses gathering RX.

Allocate a jumbo buffer pool for these chips and configure "max RX packet
size" register according to MTU.

According to wpaul's comment, 8139C+ only support 64 TX/RX descriptors

Add hardware csum offload support for MAC style 2 chips, which include
8102E, 8102EL, 8168C, 8168CP and 8168D.

Obtained-from: RealTek r8101-1.009.00 r8168-8.008.00


Add RE_C_AUTOPAD capability to indicate hardware could correctly pad
short ether frames.  Turn it on for newer version of 8168B (0x38000000
and 0xb8000000) and MAC style 2 chips; manually padding short UDP packets
for newer version 8168B will result in incorrect UDP csum, while manually
padding short ICMP packets for MAC style 2 chips will result in both
incorrect IP header csum and incorrect IP length (o_O)

- Adjust PCI latency timer on all types of chips
- Adjust PCI cache line size for 8110/8169 chips
- For certain revision of 8101E, reading MAC address from IDRx may not
  work; read from EEPROM instead
- Add comment that adjusting config1 and config5 may cause unrecoverible
  disaster

Obtained-from: RealTek Linux drivers

Add some PHY fixups before we do mii_phy_probe()

Obtained-from: Realtek BSD driver v176

Bring in some PCI register settings from RealTek BSD driver v176.  Disable
the PCI register configuration for "style 2 MAC", add comment about it.

- Read ethernet address from IDRx registers.
  Obtained-from: RealTek BSD driver v176
  This eliminates the need to read/config EEPROM.  Put EEPROM related
  functions under RE_USE_EEPROM; disabled by default
- Maintain re_softc size no matter what kernel options we are using
- Remove RE_DISABLE_HWCSUM; we could do it by clearing RE_C_HWCUM

- Nuke re_type, add RE_C_8139CP to indicate the chip is 8139C+
- Change hardware revision mask from 0x7cc00000 to 0xfc800000
  Obtained-from: Realtek BSD driver v176
- Convert MAC mode to MAC version and save MAC version in softc
  Obtained-from: Realtek BSD driver v176
- Add hardware revision 0x34800000(8102E) and 0x28000000(chip name is unknown)
  Obtained-from: Realtek BSD driver v176

Rework re_probe()

Increase default RX/TX descriptor count from 64 to 256

Use hardware timer to simulate interrupt moderation.  Old devices will no
longer be livelocked when they are receiving on GigE line.  Newer devices
also gain well controlled interrupt rate.

If hardware supports interrupt moderation (e.g. 8168B, 8168C), you could
also use hardware based interrupt moderation, however, due to lack of
necessary information it does not work as reliably as simulated interrupt
moderation.  It is _not_ recommended currently.

By default, PCI-E devices' simulated interrupt moderation timer is set to
75us, while PCI devices' is set to 125us.

- According to Realtek's BSD driver v176, we could always write to MISSEDPKT
- Use pci_get_pciecap_ptr() to decide whether a given chip is PCI-E or not
- Rename re_flags to re_caps; we will need a real re_flags soon

- It does not make sense to disable TX interrupt moderation
- Add field in softc to store RX related interrupt bits

This cleanup eases upcoming changes.

Add RX interrupt moderation suport for PCI-E GigaE chips.

Interrupt moderation register position is obtained from Realtek's
BSD driver v176.
The meaning of the IM register bits is partially reverse engineered:
RX timer position and unit.

This kind of interrupt moderation does not work on PCI GigaE chips.

Get bus clock, which will be used to fix broken TCTR setting (hardware timer,
interrupt moderation related)

Add tunable for RX/TX descriptor count

Don't assume that RE_RX_DESC_CNT and RE_TX_DESC_CNT are always same

Move some macros from if_rereg.h to if_revar.h; regroup them

re_chain_data is never used

- For relative newer parts (8168B), setting MTPS (max transmit packet size)
  according to MTU makes jumbo frame + TX csum offloading work.  However,
  for old ones (8169), setting MTPS does not have much effect.
- Reduce max jumbo frame size from 9018 to 7440 (according to DS)
- Fix MTU setting in re_ioctl

Transmit csum offload does not work at all on certain hardware revision
once frame length exceeds certain threshold (different parts seems to
have different thresholds).  Borrow code from ip_output to do software
csum, if transmit csum offloading is enabled and frame length exceeds
hardware's threshold.

8169, 8169S, 8169SB and 8168B are tested, while 8169S and 8169SB does not
seem to have this bug.

- Don't substract ETHER_ALIGN from the fragment length, we don't do
  m_adj(ETHET_ALIGN) in re_newbuf()
- If one fragment of a multi-fragment packet recolletion fails, we
  drop will consecutive fragments of this packet.
- All of the TX descs in TX ring could be used; there is no need to
  reserve RE_TXDESC_SPARE TX descs

Rework re_newbuf() and re_encap()

- Instead of using magic number 4 define it as RE_TXDESC_SPARE
- Clear if_timer only if all TX descs are free
- Clear IFF_OACTIVE only if more than RE_TXDESC_SPARE TX descs ar free

By default do not enable hardware csum on PCIe re(4), which trashes
packets intermittently if csum offload is enabled.  This problem does
not seem to plague PCI re(4).

The pattern of trashed packets is not yet identified.  From the tcpdump
information provided by Joe, the packets' size should not be the direct
cause.  Hardware bug?

Reported-by: Joe Talbott <josepht@cstone.net> (RTL8101E, PCIe re(4))

# Same problem is reported to FreeBSD by two RTL8168B(PCIe re(4)) users.

- Don't call m_adj() to make RX buffer's _payload_ on longword aligned,
  because some re(4) chips (e.g. RTL8101E) require RX buffer to be
  8-bytes aligned.  This change shows no noticeable performance change.
  Reported-by: Joe Talbott <josepht@cstone.net>
- Avoid writing extra hardware registers by writing 2 bytes to IDR4
  instead instead of writing 4 bytes, bacause:
  1) the extra two registers after IDR5 are reserved.
  2) accessing arpcom.ac_enaddr[6,7] should be invalid.
- Add a flag field in re_softc and re_hwrev.  Currently only one flag,
  RE_F_HASMPC, is defined.  This flag is used to indicate whether the
  hardware has MPC register or not, so we can avoid writing to MPC's
  position, if that position is reserved.
- Move descriptor ring address setting up before RX/TX enabling, since
  some re(4) chips (e.g. RTL8101E) will try accessing descriptor ring
  immediately after RX/TX is enabled, which results in intermittent
  kernel panic or system hanging.
  Paniced-by: Joe Talbott <josepht@cstone.net>
- Avoid calling re_init(), if hw.reX.tx_moderation is changed but NIC
  is not up yet.
- Const-fy global hardware id arrays and nuke unused macro while I'm here.

Thank Joe Talbott <josepht@cstone.net> to help debugging and provide
valuable information (esp. locating the problematic RX/TX enabling :)

Thank dillon@ to provide debugging hints.

Tested-by:
  Joe Talbott <josepht@cstone.net> (RTL8101E)
  swildner@ (onboard RTL8169S) (*)
  me (RTL8169S)

# (*) swildner@'s card is still half broken even after this commit :\

Sync re(4) with FreeBSD:
- Add support for RealTek 8169SC/8110SC and RTL8101E devices.  The latter
  is a PCIe 10/100 chip.
- Add support for RealTek RTL8168(B?)
- Fix EEPROM reading code
- Disable diagnostic code in re_attach() by default.  It is almost useless
  and has caused much trouble.
- Manually padding small IP datagrams to work arround hardware checksum
  offload bug [1].  Enable IP/TCP/UDP checksum offload after this fix.
- Work arround hardware TX bug in some PCIe re(4) devices:
  The TX command, which is issued when there is transmission in progress,
  will get lost [2].
  So at the end of re_txeof(), if there are still packets sitting in the
  TX ring, we kick the TX engine again.
- Add a sysctl hw.reX.tx_moderation to turn on/off TX moderation.  It is
  on by default.
- Move softc related structs from if_rereg.h into newly created if_revar.h

Thank Bill Paul (wpaul@freebsd.org) and many other people for their work
on this driver.

#
# [1] Detailed description of this bug is at:
#     FreeBSD dev/re/if_re.c rev1.70 by wpaul@freebsd.org
#
# [2] Detailed description of this bug is at:
#     FreeBSD dev/re/if_re.c rev1.71 by wpaul@freebsd.org
#