From owner-freebsd-hackers Fri May 21 11:14:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5840514E3B for ; Fri, 21 May 1999 11:13:56 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA29633; Fri, 21 May 1999 11:06:03 -0700 (PDT) Date: Fri, 21 May 1999 11:06:01 -0700 (PDT) From: Julian Elischer To: Mark Tinguely Cc: grog@lemis.com, brian@Awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Number of TUN devices In-Reply-To: <199905211328.IAA01990@plains.NoDak.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 21 May 1999, Mark Tinguely wrote: > (discussion moved from -questions to -hackers; bits included) > > > On Thursday, 20 May 1999 at 9:13:12 -0500, Mark Tinguely wrote: > > > FYI: > > > > > > I am playing with the idea of a direct-insert PPP for future SONET/ATM/DSL > > > PPP connections. here compression/ACCM are not a concern but higher data > > > rates make the kernel/user space copying (x2 once on each device inteface) > > > and the prcessing copying can be a concern for throughput. I am not bad > > > mouthing the tun driver; it is an excellent driver for serial devices that > > > needs to PROCESS the packets from/to the PPP link. > > > > > > In the SONET/ATM/DSL world, the PDUs will already be in mbufs from the > > > device driver. The MRU/MTU can be much larger. The data packets do not > > > need to compressed/encrypted/ACCM-ed, so the for those opened NCPs, the > > > data packets can be placed directly into the appropriate kernel protocol > > > stacks. the diagnostic, and control packets can still be processed in > > > user space via a protocol socket. > > > > > > Have you experimented what kind of through-put the NOS-TUN can handle? > > > I suspect that this model would be good enough for DSL speeds. > > > > Why are you thinking of using user PPP for this? As you say, at the > > data rates you're thinking of, it's not an optimal solution. This is a 'natural' for the netgraph code we use for the Interjet. (available from ftp://ftp.whistle.com/pub/archie/netgraph/index.html ) we use it together with the our mpd ppp daemon, and kernel based ppp modules for all sorts of networking combinations. > > no, only the LCP, NCP, authenication, dignostic messages for debugging > is done in user space. this is small traffic to setup/maintain/tear down > the connections, especially when you consider we are talking "PVC" in most > cases. the network traffic will be either directly forwarded to the > appropriate network stack, quietly discarded, or sent back to the originator > depending on the state of the link/network protocol. > > again, I am dealing with a situation where the packets do not have to > be processed, unlike the serial PPPs. and on the downside, I lose the > alias feature found in user PPP (which hopefully natd could fill in). > > > This is also probably material for -hackers. > > moved. > > --mark. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message