amd-xgbe ("ax"): interface RX byte counter stays 0 (HWSTATS)

[ThomasE]

amd-xgbe ("ax"): interface RX byte counter stays 0 (HWSTATS) — Reporting → Traffic shows no download

On a 10G WAN port driven by the AMD amd-xgbe driver (interface "ax"), the interface RX byte counter stays at ~0 even under several Gbit/s of inbound (routed) load, while TX is counted correctly. As a result Reporting → Traffic shows almost no "In" throughput even though the line is saturated. The data plane is fine — routing carries the traffic and a packet capture sees it — only the accounting is wrong. It looks like the driver advertises HWSTATS but never populates the RX hardware statistics.

Environment

OPNsense 26.4.1p2 (Business Edition)
NIC: AMD 10GbE — pciconf: ax1@pci0:8:0:5 vendor=0x1022 device=0x1458
Driver: amd-xgbe, version 1.0.3, firmware 16.118.33
Interface role: WAN, 10GBase-SFI, link up
At capture time: several Gbit/s inbound (download), ~60-80 Mbit/s outbound
Symptom

"In (bps)" under Reporting → Traffic is essentially flat (a few hundred bps), while "Out" and the pcap-based "Top hosts in" graph show real traffic. netstat confirms it, RX bytes stay at ~0 while TX is fine:

Code Select Expand

netstat -I ax1 -w 1 (WAN, under load) input ax1 output packets errs idrops bytes packets errs bytes colls 2 0 0 158 13340 0 7568812 0 1 0 0 64 11611 0 7484747 0 2 0 0 128 11775 0 7553285 0
~1-2 pkt/s and ~64-158 B/s inbound is physically impossible for a link doing multi-Gbit of routed traffic. The packets clearly arrive (routing works, tcpdump/iftop see them), they are simply not counted.

Evidence it is a counter issue, not the data path

sysctl dev.ax.1 — the driver's per-queue byte counters all read 0, including TX, which is demonstrably active at the iflib layer:

Code Select Expand

rxq_bytes[0..11]: 0 txq_bytes[0..11]: 0 ... dev.ax.1.iflib.txq00.txq_processed: 1187888204 (TX is flowing) dev.ax.1.iflib.txq00.r_enqueues: 1160571460 ... dev.ax.1.drv_info: driver: amd-xgbe version: 1.0.3 firmware-version: 16.118.33
ifconfig shows the HWSTATS capability set on the interface (IPs/MAC redacted):

Code Select Expand

ax1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4800028<VLAN_MTU,JUMBO_MTU,HWSTATS,MEXTPG> media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>) status: active
My reading: because HWSTATS is set, the stack pulls the interface counters from the driver's hardware statistics instead of counting in software. The driver's RX hardware byte counter appears to stay at 0 (TX works), so if_ibytes never increments — hence the dead "In" graph.

Already ruled out

Suricata / IDS: never enabled on this interface.
Offloading: hardware checksum, TSO and LRO already disabled; VLAN hardware filtering disabled.
Not a routed-subnet / transfer-net artefact: that only affects the pcap-based top-talkers list; the plain interface byte counter is a separate mechanism.

Questions

Is this a known limitation of amd-xgbe in the current base, and is it fixed in 26.7 / FreeBSD 15.1?
Is there a supported way to make the stack fall back to software counting — e.g. is "ifconfig ax1 -hwstats" honoured by this driver, and can it be made persistent (and is it safe to toggle on a production link)?
Is anyone running a WAN on an "ax" port with correct Reporting → Traffic (RX) numbers?

Thanks in advance.

diagnostics are from my own box, write-up is AI-assisted — happy to post more output.

[BrandyWine]

Is the cpu being fully offloaded to the NIC now?

You can try disabling this feature for individual NIC functions using sysctl.
Or use ifconfig ax1 -tso4 -tso6

So 1st try that.

To me it just sounds like a driver issue.

[TimS]

Is the cpu being fully offloaded to the NIC now?

You can try disabling this feature for individual NIC functions using sysctl.
Or use ifconfig ax1 -tso4 -tso6

So 1st try that.

To me it just sounds like a driver issue.

@BrandyWine thanks for the input.

TSO is already disabled on this interface.
The ifconfig ax1 output in the original post only shows:

Is the cpu being fully offloaded to the NIC now?

so neither TSO4 nor TSO6 is currently enabled. Checksum offloading and LRO are disabled as well.

That is also why I'm leaning more towards a driver/counter issue at this point. The interesting part is that inbound traffic is clearly present on ax1 in packet captures and is routed normally, while if_ibytes and the driver's RX byte counters essentially stay at zero.
TX accounting works.

The remaining thing I'd like to test is disabling HWSTATS, e.g.:

Code Select Expand

ifconfig ax1 -hwstats
to see whether FreeBSD then falls back to software accounting and the RX counter starts increasing.

Do you happen to know whether -hwstats is properly supported by amd-xgbe / iflib, and whether toggling it on a live interface causes any interface reinitialization or traffic interruption?
Because I suppose it does.

Thx!

Tim :)

[nero355]

NIC: AMD 10GbE — pciconf: ax1@pci0:8:0:5 vendor=0x1022 device=0x1458
Driver: amd-xgbe, version 1.0.3, firmware 16.118.33

What is the actual chip being used for this "AMD" NIC ?!

If it's Aquantia or RealTek and even Broadcom or Mellanox then you have got a great chance it's driver related and you need to talk to FreeBSD developers/maintainers about it :)

[patient0]

If it's Aquantia or RealTek and even Broadcom or Mellanox

That type of NIC is in the Desico appliances, like the DEC7xx or DEC8xx. It's from AMD and usually baked into the SoC.