[Top] [All Lists]

Re: TCP IP Offloading Interface

To: davem@xxxxxxxxxx, jros@xxxxxxxxx
Subject: Re: TCP IP Offloading Interface
From: "David griego" <dagriego@xxxxxxxxxxx>
Date: Tue, 15 Jul 2003 09:28:10 -0700
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, alan@xxxxxxxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
Ok I've taken a look at your scheme and I have a few questions.

From: "David S. Miller" <davem@xxxxxxxxxx>
You also ignore the points others have made that the systems HAVE
SCALED to evolving networks technologies as they have become faster
and faster.

This is not true in the embedded space. As I keep pointing out typical embedded processors don't have as many free cycles as server computers.

My RX receive page accumulation scheme handles all of the
receive side problems with touching the data and getting
into the filesystem and then the device.  With my scheme
you can receive the data, go direct to the device, and the
cpu never touches one byte.

RDDP tries to get around needing a large amount of RAM on the NIC to collect all of this data before writing it to the OS memory. Also, this store and forward architecture you recommend adds latency in collecting all of this data before moving it to the OS. Finally, I recall some resistance to page flipping which could also lead to walking page tables. More latency. After some extremely large amount of time your receive data has made it to your application. Do you have a suggestion on how we could get around all of this store and forward without RDDP? Just avoiding the CPU copy is not the only issue.

I actually welcome Microsoft falling into this rathole of a
technology.  Let them have to support that crap and have to field bug
reports on it, having to wonder who created the packets.  And let them
deal with the negative effects TOE has on connection rates and things
like that.

Would it be shame if they found away around this "problem" you see and are successful and Linux failed because you felt the community is not able overcome these though obstacles?

Linux will be competitive, especially if people develop the scheme I
have described several times into the hardware.  There are vendors
doing this, will you choose to be different and ignore this?
Your ideas are good, but they leave in this store and forward issue that I mentioned. A good alternative would be one that kept things simple as you suggested, but didn't introduce all of this latency.

The new MSN 8: smart spam protection and 2 months FREE*

<Prev in Thread] Current Thread [Next in Thread>