> > I don't know about the packet filtering, but PPP compression has to be done
> > after protocol encapsulation (you compress the ENTIRE PPP packet, not just
> > the IP(/IPX/Appletalk/BNCP/...) data payload.  I suppose it COULD be done
> > in pppd; but the overhead of switching from kernel to user mode twice would
> > be most inconvenient.
> 
> i'm not sure that i'd buy that without a measurement to prove it.
> 
> 1 PPP line is what?  at most 57.6k/sec?  150k/s?  If done in an
> optimized manner (e.g. some shared memory region, or something), you'd
> not have to pass the data back and forth, and, if multiple packets
> could be done at once, it wouldn't necessarily be _that_ many extra
> user-kernel switches per second...

Well, if you stick to running PPP over async lines, sure.  But there is
nothing to stop you from putting in a sync card (and driver) and run PPP
over eg. a T1 talkig to a Cisco or something...

> With an eye to asking: "is the extra 35k+ (on i386) of wired kernel
> memory a good deal" for the average person who has PPP in his kernel.
> (Note that there are quite likely a fair number of people who have PPP
> in their kernels but don't actually use it...  Now, perhaps that's
> their problem, but taking away 9 pages of core isn't a great idea in
> any case...)

Wouldn't it be better to have the compression code optional with some
compile time option to decide on wether or not you should have it in
the kernel in the first place?

Thorsten
--
Thorsten Lockert        | postmaster@sigmasoft.com | Universe, n.:
1238B Page Street       | hostmaster@sigmasoft.com |         The problem.
San Francisco, CA 94117 | tholo@sigmasoft.com      |