Date: Fri, 21 May 1999 08:28:59 -0500 (CDT) From: Mark Tinguely <tinguely@plains.NoDak.edu> To: grog@lemis.com, tinguely@plains.NoDak.edu Cc: brian@Awfulhak.org, freebsd-hackers@freebsd.org Subject: Re: Number of TUN devices Message-ID: <199905211328.IAA01990@plains.NoDak.edu>
next in thread | raw e-mail | index | archive | help
(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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905211328.IAA01990>