Date: Fri, 21 May 1999 11:06:01 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Mark Tinguely <tinguely@plains.NoDak.edu> Cc: grog@lemis.com, brian@Awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Number of TUN devices Message-ID: <Pine.BSF.3.95.990521105733.23621B-100000@current1.whistle.com> In-Reply-To: <199905211328.IAA01990@plains.NoDak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990521105733.23621B-100000>