Rick Jones wrote:
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.
It should be *very* similar to having 2 ports talking to 2 remote systems..the
only thing my patch does is fix up arp to work, if I remember correctly. The
rest of the magic is normal user-space API like binding to a local address
and the BIND_TO_DEVICE ioctl.
FWIW, just why do you want to have the system be able to do that anyway?
Allows a single system to be a complete network traffic generator...used
for making my test devices. Good for testing latency in a network under
test since you don't have to worry about synchronizing clocks too..
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.
It is not necessarily the most efficient way to generate bulk traffic,
but I think it is a valid test.
I use non-blocking IO and poll(). It is true that both sides may have
full TX and/or RX buffers, but the code still works fine. I can adjust
my tool to request any speed any either direction, so I will see if
the bi-directionality makes a difference...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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
