Ben, as for your test I think something is messed up in your patches,
as no one else seems to be reporting your freezes.
I will run some tests on standard kernels if I can still reproduce on
2.6.14. If it is bugs in my patches, it's subtle..since turning off
TSO fixes it.
IIRC you said you had patches that allowed TCP/IP traffic for IPs that were on
the local system to flow-out onto the network and back-in again right? I
suspect that could have some rather different timing patterns than standard
networking where packets for local IP's never get to the NICs.
FWIW, just why do you want to have the system be able to do that anyway?
When you run your tests, do you ever do tests with sending significant
traffic both directions on a single socket?
Shall I follow up with some data? I can reproduce this at will with
netperf and a couple of scripts.
I can say that "stock" netperf has no _single-connection_ bidirectional tests,
so unless someone has added them to a private copy any bidirectional traffic
with netperf involves more than one TCP connection.
At times I've tought about doing a single-connection, bidirectional netperf
test, but kept balking (perhaps not for any valid reason) at needing to use
select/poll to keep the thing from having a potential deadlock - both sides
trying to send into full socket buffers and neither reading data to let the
other make forward progress - or both going into recv() when there is no data to
be read. Thoughs about using non-blocking sockets kept wrapping me around the
axle of spinning like a banshee and so obfuscating the CPU utilization calculations.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
