From owner-freebsd-hackers  Wed Jun 18 18:19:47 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA24204
          for hackers-outgoing; Wed, 18 Jun 1997 18:19:47 -0700 (PDT)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA24195
          for <hackers@freebsd.org>; Wed, 18 Jun 1997 18:19:43 -0700 (PDT)
Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1)
	id 0weVqE-00037F-00; Wed, 18 Jun 1997 18:16:50 -0700
Date: Wed, 18 Jun 1997 18:16:49 -0700 (PDT)
From: Tom Samplonius <tom@sdf.com>
To: sthaug@nethelp.no
cc: ccsanady@scl.ameslab.gov, hackers@freebsd.org, matt@3am-software.com
Subject: Re: Network concurrency problems!?
In-Reply-To: <4913.866668314@verdi.nethelp.no>
Message-ID: <Pine.BSF.3.95q.970618181004.11965A-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Wed, 18 Jun 1997 sthaug@nethelp.no wrote:

> > > Also, if you expect a PPro-200 to saturate 4 100 Mbps links, I think you
> > > are a wee bit optimistic. (One link, no problem.)
> > 
> >   Why?  As long as the ethernet hw is fast, is should be no problem.
> 
> It's a problem because of the resource usage of the TCP/IP stack and the
> driver.
> 
> The FreeBSD TCP/IP stack is good, but it's not the most efficient. As far
> as I know, there is still an extra pass over the data to perform the TCP
> checksum, for instance.

  Would a TCP socket have more system overhead than a file on a UFS
filesystem?  I guess you can tess this by running dd on a mfs, and
tcpblast/netpipe/ttcp on loopback?  Somehow I think the socket would be
faster.

...
> >   However, I really doubt whether most ethernet adapters offload enough
> > functions from the main CPU.  The trend is to make very stupid
> > controllers, which are slaved to the CPU for everything.
> 
> There has been a good deal of debate on whether offloading is really the
> best idea for network protocol implementations. A lot of people have tried
> it, and a lot of people have failed.  If you look at Van Jacobson't work
> you'll find him arguing in the opposite direction: A "stupid" (in reality:
> simple and efficient) controller, and a very efficient protocol stack
> implementation.

  Not really what I was refering to.  I was thinking about controllers
that minimize interupt calls, use DMA, avoid PIO, and align data
transfered to the host.

Tom