From owner-freebsd-isdn Fri Jan 29 09:31:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12764 for freebsd-isdn-outgoing; Fri, 29 Jan 1999 09:27:38 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12744 for ; Fri, 29 Jan 1999 09:27:26 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id JAA16054; Fri, 29 Jan 1999 09:25:51 -0800 (PST) Received: from s204m82.isp.whistle.com(207.76.204.82) via SMTP by alpo.whistle.com, id smtpdx16042; Fri Jan 29 17:25:38 1999 Date: Fri, 29 Jan 1999 09:25:31 -0800 (PST) From: Julian Elischer X-Sender: julian@s204m82.isp.whistle.com To: Barry Scott cc: "'Archie Cobbs'" , hm@hcs.de, freebsd-isdn@FreeBSD.ORG Subject: RE: i4b and netgraph (was: I4B support for US ISDN?) In-Reply-To: <81C8165DD2A7D111AD700000F81F29CB02504A3A@nwcwi19.europe.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 29 Jan 1999, Barry Scott wrote: > > In order to minimize latency, all netgraph operations are functional. > > direct call vs. queuing does not have this advantage if you compare > optimum solutions using both methods. e.g. take into account > reentracy > issues and event sequencing. > > Do you queue the create hook and delete hook events? > > I'm reasured that you have queuing, shame its not the default. Its not the default because a directly called node can decide to queue, within itself. (and have the data resubmitted at dequeue time).. basically the directly called subrutine acts as a subroutine of the caller, but with the internal knowledge of the callee. It's also slightly slower and un-needed for 98% of the operations. These nodes a VERY SIMPLE, and a packet may go through 6 of them. 6 queueing delays would be excessive. (look at this exact problem in STREAMS). It was decided to allow queueing (either sender or receiver can specify that it should be queued) but to use direct calling specifically because of the bad experiences of STREAMS. direct calling can still queue, but queueing cant go back to direct calling. Direct calling also allows return values, which are sometimes useful, and lost if you decide to queue. julian > > Barry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message