https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297383
--- Comment #5 from tunnelweb <[email protected]> ---
Happy to test it, though it will be tomorrow before I have results.
One complication: I am on OPNsense 26.7 (FreeBSD 15.1-RELEASE-p1) where xhci is
compiled into the kernel, so picking up the tunable would mean building a whole
kernel. Rather than do that I have written a small loadable module that writes
IMOD(0) directly at runtime, so I can set the interval and change it back
without rebooting. It reads 0x01f4 before writing anything, which matches
XHCI_IMOD_DEFAULT, so it is addressing the right register. Same value your
patch
would set, just applied later. I have left the bulk_callback_cpuset mask out as
you suggested; this is an AMD FCH USB 3.0 controller, not Meteor Lake.
A data point that may interest you before I run it. My download is already
983 Mbps at the stock 125us, where yours was 278. That is with the RX
aggregation hold timer fix from this bug, axge_bulk_size[0] 0x004f -> 0x0400. I
suspect your change and that one are addressing the same bottleneck from
opposite ends: bigger aggregated transfers need fewer interrupts, so the
moderation interval stops mattering, and vice versa.
Which leaves transmit, and that is the part I could never explain. There is no
transmit-side equivalent of the aggregation fix, so if your change helps
anything here I would expect it to be that.
To keep the numbers straight, since they differ from the ones earlier in this
bug: those were over the WAN through NAT and a VLAN tag (979 down, 465 up). The
figures I will be comparing against are local iperf3 with no routing involved,
923 down and 699 up, measured on the same adapter. I have also since moved the
firewall to different hardware, an HP t530 (AMD GX-215JJ) rather than the
Intel i5 the earlier figures came from. It reaches 983 Mbps on the WAN at about
39% CPU, so receive is clearly not host limited. Transmit does not look host
limited either, for a different reason: the slower of the two machines produced
the higher transmit figure, which is the wrong way round if the CPU were the
constraint.
I will test locally rather than over the WAN, since my plan caps upload at
500 Mbps and would hide any improvement. Will report both directions at 125us
and 16us. o7
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.