[Bug 297383] axge(4): RX aggregation timer far too short, uninitialised reads on control transfer failure, TX padding bit never set

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297383

            Bug ID: 297383
           Summary: axge(4): RX aggregation timer far too short,
                    uninitialised reads on control transfer failure, TX
                    padding bit never set
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 273563
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=273563&action=edit
Fix RX aggregation timer, uninitialised control reads, TX padding bit, and RX
queue depth

axge: fix throughput and stability on AX88179/AX88179B

Four independent problems, found while getting an AX88179B to run at line rate
on a gigabit WAN.

The RX aggregation hold timer for SuperSpeed gigabit was 0x004f, which is too
short for the part to accumulate anything. It emits one frame per bulk
transfer, so the link is limited by USB round trips rather than bandwidth.
Sweeping the field live during a transfer:


 0x004f -> 705 Mbps, 58k pkt/s
 0x0100 -> 952 Mbps, 79k pkt/s
 0x0400 -> 979 Mbps, 81k pkt/s
 0x4000 -> 979 Mbps, 81k pkt/s
Returning to 0x004f reproduced the lower figure. 0x0400 reaches line rate;
larger values only add latency.

axge_read_cmd_1() and axge_read_cmd_2() discarded the return value of
axge_read_mem() and returned the buffer regardless. On failure that buffer is
uninitialised, so callers act on stack contents. These are control transfers
sharing the bus with bulk traffic and they do fail under load: the MII layer
saw random link status and flapped the link several hundred times during a
saturating transfer, versus none at idle. On a DHCP WAN the lease is lost when
that happens.

AXGE_PADDING was defined but never set. The part waits for more data when a
frame plus its header is an exact multiple of wMaxPacketSize, wedging the TX
pipe until something resets it; the stack reports ENOBUFS meanwhile. Linux's
ax88179_178a sets the bit under the same condition.

Only one RX transfer was in flight, leaving the bulk IN endpoint unarmed for
the whole time the completion callback spends demultiplexing a burst. Four
matches if_ure(4)'s URE_MAX_RX. Eight regressed badly, presumably past what
xhci(4) will keep on a bulk endpoint ring.

Items 1, 2 and 4 are not specific to the B revision and should affect any axge
device; item 3 was only observed there.

Tested on: FreeBSD 15.1-RELEASE-p1 (OPNsense 26.7), ASIX AX88179B in a TP-Link
UE306, 1000baseT full duplex over SuperSpeed, VLAN tagged WAN. Before: 57-73
Mbps with climbing input drops, and DHCP frequently failing outright; the
documented workaround is a USB quirk forcing configuration 1 so cdce(4)
attaches instead, which is stable but limited to ~350 Mbps. After: 979 Mbps, no
errors, no drops, no TCP retransmissions.

Reproduction of item 1, on any AX88179-class adapter at gigabit over
SuperSpeed, with a sustained transfer running: the hold timer lives in
axge_bulk_size[0], bytes timer_l/timer_h in sys/dev/usb/net/if_axge.c. Default
is 0x004f. Patch it to 0x0400, rebuild if_axge.ko, and compare throughput and
packets/sec. I measured by exposing the field as a sysctl so it could be swept
live during a single uninterrupted transfer, which avoids the link bounce
destroying the traffic being measured.

Item 2 is visible by inspection: both functions ignore the return value of
axge_read_mem() and return the buffer, which is untouched when the transfer
fails.

I have only this one adapter, so I cannot confirm items 1, 2 and 4 on plain
AX88179 or AX88179A hardware, though nothing in them is revision specific.

-- 
You are receiving this mail because:
You are the assignee for the bug.