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 majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
