From owner-freebsd-hackers Mon Jan 6 13:54:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02513 for hackers-outgoing; Mon, 6 Jan 1997 13:54:04 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA02504 for ; Mon, 6 Jan 1997 13:53:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA12639; Mon, 6 Jan 1997 14:44:16 -0700 From: Terry Lambert Message-Id: <199701062144.OAA12639@phaeton.artisoft.com> Subject: Re: New Networking framework for BSD To: dennis@etinc.com (dennis) Date: Mon, 6 Jan 1997 14:44:16 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <3.0.32.19970105130424.0068f454@etinc.com> from "dennis" at Jan 5, 97 01:04:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> 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.