Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jan 1997 14:44:16 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        dennis@etinc.com (dennis)
Cc:        hackers@freebsd.org
Subject:   Re: New Networking framework for BSD
Message-ID:  <199701062144.OAA12639@phaeton.artisoft.com>
In-Reply-To: <3.0.32.19970105130424.0068f454@etinc.com> from "dennis" at Jan 5, 97 01:04:26 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >> Darren, see my mail drirectly to you...
> >>  you appear to have commented without reading the doc yet..
> >> I'm not trying to replace anything. Just make a framework for such
> >> services as frame relay and ATM, at the LINK level.
> >
> >Yes, I read it briefly first but wrote that with an empty mind...
> >
> >Looks like the claytons STREAMS.  How is it different to STREAMS (by
> design) ?
> 
> Yeah  really. STREAMS is a great academic product...but a monster in real
> world implementation.  Not to mention a pig. Anyone care to guess why the
> 'BSD unices blow the doors off system V performance-wise?

Because "runstreams" is only called at system call entry, exit, and a
couple other stregic times, and it is required to be called for every
layer traversal in getmsg/putmsg across a stack boundry.

In experimental implementations where the stack was run to completion
at interrupt level, streams was no more bulky or slow than the BSD
equivalents.  In addition, a number of experiments have been done
to implement "multiheaded stacks"... that is, a single monolithic
stack that exports heads for ICMP, IP, UDP, and TCP, such that
multiple traversals are not required following the initial putmsg at
interrupt time.

The problem with streams is when it is able to run, and the granularity
at which it runs.

When you look at streams implementations, I would suggest you look
at the IBM AIX adaption of the Mentat Streams system.  They were able
to resolve the latency issues (which are the issues to which you are
referring, in a sideways manner) by running the streams implementation
as a kernel thread, such that stack data runs to completion, without
the peristaltic slowdowns of running to copletion at interrupt level,
and without the Karnot map reduction required for the multiheaded
implementation.

Only in kernels which are not thread reeentrant, for which kernel
threading is unavailable, or which use high granularity locking on CPU
reentrancy (effectively ASMP for interrupt and exception handling)
have problems with streams latency... and that's not the direction
FreeBSD is headed in (apparently, from reading the SMP list).


> An issue to consider is that you dont need a new framework...virtual
> interfaces solve the problem without changing anything...

I really disagree with this... virtual interfaces cross protection
domains, and that's a problem... as much of a problem as moving the
network stack to user space (as some have suggested in research
projects trying to address these issues).

The advantage of the stremas (or xkernel framework, from the University
of Arizona up the street from me) is that they do *not* cross protection
domains.


> with a new
> framework you are likely to break compatibility with routing daemons
> (like gated)...which would render the effort worthless in the big picture.

I agree with this; however, since I haven't read Julian's paper yet,
I will reserve comment; for all I know, it looks so much like streams
I will wonder what I am complaining about if I say too much.  8-).


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701062144.OAA12639>