Ok I've taken a look at your scheme and I have a few questions.
>From: "David S. Miller" <davem@redhat.com>
>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*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:58 EST