[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

--- Comment #6 from tunnelweb <[email protected]> ---
Thanks for the patch, and for pointing me at the moderation register in the
first
place. Results are in, both directions at 125us and 16us. It makes no
difference
on this box, though I do not think that says much against the change itself.

Setup, since a couple of things had to be got right before the numbers meant
anything. I took the adapter off the ONT and put it on the LAN switch so
nothing
was routed, NATed or VLAN tagged. ue0 was aliased into the LAN subnet and given
a
/32 host route back to the test machine, because without that the return
traffic
followed the /24 out the onboard NIC and only one direction was ever landing on
ue0. That cost me a run. Load was nc in both directions and I counted bytes off
netstat -ibn on ue0 itself rather than trusting a userland figure. Link was
1000baseT full duplex, USB SuperSpeed. Each pass ran 42 seconds sampled in 3
second windows, and since the load alternates direction rather than running
both
at once, the figure below is the best window per direction rather than an
average.

  imod     RX (down)    TX (up)
  125us    987 Mbps     711 Mbps
  16us     987 Mbps     716 Mbps
  125us    987 Mbps     710 Mbps

Receive is at line rate for the media in all three, so it cannot discriminate
at
all, there is nowhere left for it to go.

For what it is worth the register really was being written, so that is one
thing
you do not have to wonder about. My module exposes the raw 32 bit readback, and
during traffic at 125us it reads 31982068, which is (488 << 16) | 500: IMODI
500,
with the IMODC down counter sitting in the top half. At 16us it reads 1769536,
(27 << 16) | 64, IMODI 64. Both values landed and read back correctly under
load.

Counters stayed clean the whole way, Ierrs 0, Idrop 0, Oerrs 0, and the torn
media word counter from the MII patch held at 0 across all three passes.

I would not read any of this as the patch being useless, only that it is
redundant on top of the aggregation hold timer change, and only here. Yours was
measured against 278 Mbps receive and mine starts at 987, so there is no
headroom
left on this box for it to recover. If anything I think it supports the two
changes being the same bottleneck approached from opposite ends: with the hold
timer at 0x0400 the transfers are already large enough that the interrupt rate
is
low, so shortening the moderation interval only lets the controller interrupt
sooner for work that is not there. Someone whose receive is not already at line
rate would be a far more useful test of it than I am, and I would like to see
it
land for the people it does help.

Usual caveat, this is one controller, an AMD FCH USB 3.0, and one adapter. The
rig is still set up, so if there is anything else you would like tried on it,
just say and I will run it.

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