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

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.

show more ...

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 i

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)

show more ...

- 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 inste

- 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

show more ...

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 b

- 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

show more ...

- 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

- 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

show more ...

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 hardw

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.

show more ...

- 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 re

- 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

show more ...

- 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

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.

show more ...

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

- 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

show more ...

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 t

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.

show more ...

- 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 frag

- 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

show more ...

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

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.

show more ...