[BUG] e1000e: I219 with jumbo MTU: RX CRC errors for unicast DAs not in the RAR (promiscuous/bridged ports)

Hi,

On I219-LM (8086:15bb rev 10, pch_cnp) with MTU 9000, frames addressed
to a unicast MAC that is not in the RAR fail with rx_crc_errors at
roughly 0.1% of frames (rx_errors rises by exactly twice that; the
length and alignment counters stay at 0), while the same stream
addressed to the port's own MAC is clean. A port enslaved to a bridge or
OVS is always in this state, since e1000e_set_rx_mode() skips
e1000e_write_uc_addr_list() under IFF_PROMISC.

Hardware: Dell OptiPlex 7060 (BIOS 1.32.0) and HP ProDesk 600 G5 Mini
(BIOS R22 02.24.00), both I219-LM 8086:15bb rev 10, NVM 0.5-4. Kernel
7.0.14 (Proxmox); e1000e_set_rx_mode(), e1000e_write_uc_addr_list(),
e1000_rar_set_pch_lpt() and e1000_lv_jumbo_workaround_ich8lan() are
unchanged in net-next.

Setup: lan0 (the I219) is an OVS port, so IFF_PROMISC and RCTL UPE|MPE
are set. A VLAN device on lan0 carries the host's IP with its own MAC
(different from lan0's). The sender is behind 10GbE switch ports; the
receiver's switch port is 1GbE.

Test: 1 GiB of TCP (ssh, MSS 8948) pushed into the I219 host, counting
rx_crc_errors before and after:

                                              host 1      host 2
  DA = lan0's own MAC (RAR[0])                  0, 0        0, 0     per GiB
  DA = the VLAN device's MAC (not in RAR)     438, 429    416, 417   per GiB

Workaround, confirmed on both hosts: giving the VLAN device the port's
own MAC, so the host's traffic is addressed to RAR[0], brings the same
test to 0, 0 per GiB. Frames to the MACs of bridged guests behind the
port cannot be helped that way and remain affected.

All of the following are needed. Removing any one gives 0 errors:
  - frame size: path MTU 3000/5000/7000/9000 -> 0 / 0 / 80 / ~370
  - back-to-back line rate: the same jumbo frames paced at ~1000/s -> 0;
    the same 1 GiB from a 1GbE sender through the same switch -> 0
    (only a faster ingress port drained into the 1GbE port produces
    minimum-IPG back-to-back frames)
  - a DA that is not in the RAR (table above)

Not affected (each tested, no change in the error rate): CPU C-states
(holding /dev/cpu_dma_latency at 0 -> 380/GiB), the disable-k1 private
flag, GRO, cable, switch EEE/jumbo settings. rx_missed_errors stays at
~0, so this is not an RX FIFO/descriptor overrun.

My reading of why (please correct me): the I219's PHY-MAC interconnect
runs at 1.25 Gb/s 8b/10b (datasheet section 2.2), i.e. no headroom over
1000BASE-T. e1000_lv_jumbo_workaround_ich8lan() copies the RAR into the
PHY (e1000_copy_rx_addrs_to_phy_ich8lan()), seeds PCH_RAICC(i) with
~ether_crc_le() of each RAR address and sets FFLT_DBG; the PHY register
fields described as "Crop ANM DA Jumbo" / "Filter on 1Gbps ... jumbo
fix" suggest the PHY drops the DA of known addresses to gain bandwidth
and the MAC restarts the CRC from the per-address seed. A frame whose
DA is not in that table gets no crop, and back-to-back long frames then
overrun the interconnect.

Two consequences in the driver, from reading the code:

1. Under IFF_PROMISC, secondary unicast addresses (a VLAN, macvlan or
   bridge MAC on top of the port) are never written to the RAR, so they
   never get the jumbo fix. This is the case measured above.

2. Even without promiscuous mode, e1000e_write_uc_addr_list() ->
   rar_set() writes only RAL/RAH (SHRAL/SHRAH), while PCH_RAICC and
   the PHY's copy are refreshed only in e1000_configure_rx(). An address
   added after the interface is up should have the same problem until
   the next reset or MTU change. (Not tested.)

Possible directions, if the analysis holds:
  - while the jumbo workaround is enabled, program secondary unicast
    addresses into RAR/SHRA even under IFF_PROMISC, and re-run the
    PCH_RAICC + PHY copy whenever the RAR changes;
  - for DAs that cannot be in the RAR at all (bridged guests' MACs, or
    an ME holding SHRA via FWSM.WLOCK_MAC), is there a hardware way to
    sustain line-rate jumbo for them? If not, a one-time warning when a
    jumbo MTU is combined with promiscuous mode on pch2lan+ would save
    the next person a long hunt.

I worked through this with the help of an AI assistant (Claude); the
numbers above were measured on my two machines.

I can test patches on both machines (Secure Boot is on, so that goes
through a MOK-signed module) and run further measurements if useful.

Thanks,
Andrei