Date: Wed, 10 Jan 1996 18:45:24 -0500 From: dennis@etinc.com (dennis) To: Nate Williams <nate@rocky.sri.MT.net> Cc: hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601102345.SAA00248@etinc.com>
next in thread | raw e-mail | index | archive | help
>[ kernel PPP vs. user-land PPP ] >> >Bloating the kernel with the features of user-land ppp is not a good >> >thing. Also, it's *very* easy to debug the user-land version where the >> >kernel version is *much* harder to debug. No reboots necessary. ;) >> >> This is ridiculous....memory is memory and you use more with a user >> level implementation than a kernel version. If your not using it its >> optioned out...so who cares? You arguably need just as much kernel >> code to provide the necessary informatoin to the user level code (if >> done properly) then if you did it in the kernel. > >Do you have *any* idea what you are talking about? As a user I *might* >not always running PPP, but if it's in the kernel I'm *always* taking >the memory hit for it if it's in the kernel. As an extreme example of >this, let's stick X inside the kernel since most folks use it. If they >don't, they can 'option it out'. I'm sure it would be much faster in >the kernel. Heck, why not /bin/sh as well? It's *always* used by at >least one process. Yes...actually i have a pretty good idea what im talking about. There are things that belong in the kernel and things that dont. Thinks that interarct with USERS clearly belong in user space, because you can't save a process switch anyway and users are clearly an incremental variable. ppp, on the otherhand, is a network interface, whose traffic is most usually routed to another network interface. Since everything else is in the kernel, its nonsensical to pull data out just to do a tiny bit of processing (probably none actually) just to push it back in. Your beating up your system for no reason, and if you're charging customers then your cheating them as well. > >> Improving kernel debugging is not difficult...we debug much more >> complicated things than ppp within the kernel space. The fact than >> pppd debugging is poor is not a good reason to adulterate the entire >> mechanism. > >But the idea is to *remove* things from the kernel that make sense to >remove from the kernel. True...but ppp in user space makes no sense. None. > >> Good datacomm should focus on the 99% and not the 1%. Imagine if you >> moved ethernet processing to user space to improve debugging? > >I doubt very much that 99.9% of the users notice the load difference >between user-land ppp and kernel ppp. What i meant is that setup is not nearly as important as passing packets, which is the bottom line here. The fact that most people feel that they need 133Mhz pentiums to run a few modems over a 56k link says something about the overhead in the software they're using, and the importance of performance. > >Downsides to adding the features to the kernel: >1) It's always in memory even if the user doesn't want it. >2) It's difficult to debug >3) It doesn't belong in the kernel since it's not a 'kernel' type of function. 1 is not true, 2 is true only because no one has added good debugging code, and 3 is simply wrong....very wrong. > >Upsides: >1) It's faster. > >Show me why your upsides is better than the downsides above? Show me >that it negatively affects a significant # of users (not in your mind, >in their mind). This is pretty easy! First of all, I think that your premise is simply wrong, or perhaps you misinterpreted what i was talking about. The memory penalty is tiny, maybe 15k, and thats not enough to outweight the only thing (other than stability) that is important in communications....and thats performance. I think what you're missing is that no one is suggesting putting entire pppd in the kernel...but that adding the couple of features that the user space implementation offers is not a lot of code and the advantages would be tremendous. In another message you said something about "a half meg" memory penalty, and on this you are WAY off, nate! Our driver implements PPP, frame relay, x.25 the board driver, debugger and user interface in about 100k, so i think that perhaps youve been playing with C++ for too long or something. Other O/Ss have full kernel ppp without talking up much space, so it clearly can be done. And lastly, I think if you took a show of hands on providers and users after asking them if they would mind using even 50k to get better performance i think that I'd be surprised to see even 1 hand not waving wildly in the air. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601102345.SAA00248>