Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!pasteur!ucbvax!MITVMA.MIT.EDU!KASTEN
From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: offloading the protocols
Message-ID: <8803210222.AA20416@ucbvax.Berkeley.EDU>
Date: 19 Mar 88 14:03:33 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 41


More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.

A second (equally important issue) is to trust your local I/O
channel.

The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).

By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.


A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:

    The cost of moving the data from disk to user is X, from user
    to network application is X, running the TCP checksum is X and
    then moving the data from the network application to the I/O
    adaptor is X. The total cost is 4X and X seems to be O(n).

This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).


Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.

Remember, this is all empirical! real testing needs to be done.

Frank Kastenholz
Atex Inc.

All opinions are mine - not my employers.....