Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc.

["David S. Miller" <davem@redhat.com>]

   From: Zachary Amsden <zamsden@cthulhu.engr.sgi.com>
   Date: Thu, 24 Feb 2000 17:56:26 -0800

   With network bandwidth approaching memory bus bandwidth, it becomes
   an issue.  A single copy receive uses 3x the bus bandwidth of a
   zero copy implementation (or worse if not aligned properly), and
   also poisons many more cachelines.

Before we discuss this point further, does anyone have real hard
evidence that cpu cycles on the client side are the issue for
the vast majority of systems out there?

In my experience cpu cycles are abundant on client machines.  Server
side is where getting precious cpu cycles back seems more important.
Client side cpu cycles are typically being expent on tasks such as
IDCT transforms to decode audio/visual streams, executing Java code,
but not copying the data from the network.

Next, have any other implementors investigated the cpu usage gains
obtainable from deferring TCP receive packet processing to user
context?  I have seen it make significant improvements, and whats more
this helps out all systems, this means old applications and
unsophisticated hardware.  (I am referring to Jakobson's idea of
nearly 10 years ago, and it appears once again he was right.)

Finally, what does RDMA do in the presence of SACK options?  Which
set of options gets kicked out?  Should the RDMA options go in
and we just drop the SACK blocks?  Or the other way around?

Later,
David S. Miller
davem@redhat.com