> 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...

yeah, data copying is bad, etc., but at low data rates it's not a
problem unless the implementation is _really_ inefficient...  And so i
wonder:
	(1) how widely will this code be used, and
	(2) what the performance impact of having it in user-land
	    would be.
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...)


cgd