https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297383
--- Comment #8 from tunnelweb <[email protected]> ---
Created attachment 273677
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=273677&action=edit
axge(4): keep four transmit transfers in flight
It was enabled, yes, though I went and proved that to myself before saying so.
I
checked the module the test ran against rather than the tree I assumed it came
from.
axge_config is 320 bytes there, against 80 in stock, so 8 transfers, 4 and 4.
The reason it is in neither patch is nothing more interesting than untidiness.
It has
been sitting in a separate tree since before I split things up for submission
and I
never folded it back in, so thank you for spotting it, it would have gone on
sitting
there. Attached as series/axge-tx-depth.patch, applies on top of the other two.
Same shape as the receive change, AXGE_N_TX_XFER 4 and the start, stall and
stop
calls become loops. The part worth your attention is axge_bulk_write_callback,
which
doesn't return early on IFF_DRV_OACTIVE any more and doesn't set it after
submitting.
With one transfer that flag was the serialisation. With four it stops the
others
picking up work while the first is on the wire, which is the point of having
them.
if_ure(4) does the same with URE_MAX_TX 4, which is where I took it from. That
is the
part I am least sure of, so do say if it wants doing differently.
Upload went 250 to 465 with it in, though that was over the WAN on the older
box
through NAT and a VLAN tag, so a direction rather than a figure.
Which leaves transmit still unexplained, which is where it has been since the
start.
At least it is one less place to look.
--
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.