Hello jamal,
On Mon, 31 Jan 2000, jamal wrote:
...
> I would like to do a performance analysis for channel vs the tty option.
> Should the channel stuff prove to be faster (seems like it will), it is
> trivial to change my code in 2.3 to use channels. In 2.2 it will have to
> stay using ttys. Generally, I dont wanna use a feature just simply
> because it is there. Speed as well as flexibility are extremely
> important.
I still haven't had a close look at your code yet, I'll try to do so
tonight before I comment =)
> Bundling everything under one daemon i think is a bad solution.
> >From a generecity aspect PPPOE is a protocol on its own as is L2TP
> etc; each has their own connection setup/teardown and discovery
> (which could be changing). They just happen to use PPP to transport
> things. You dont wanna keep changing pppd everytime one
> of these PPPoX things changes. PPP is an extremely popular framing scheme.
> I suspect there will be a lot more "PPP over X" protocols that havent been
> added yet. It is also a connection management nightmare to have pppd do
> everything. Let "your_favorite_pppoxd" tell pppd to just start or stop
> connections ('dial' or 'disconnect' to use your lingo). Use some other
> tricks to discover services (eg sockets in L2TP etc).
> I just saw another implementation of PPP over ATM which copies Michal's
> approach; I think we need to put a check on this NOW before it goes out
> of control.
Even though everything normally runs under one daemon, it does not have
to. In fact, during development I'd test things by running two copies of
the daemon on the same machine for testing PPP negotiations. Also, the
program that does the PPPoE negotiations is separate from the PPP daemon,
and I strongly agree that the daemon core should know little about
actually making connections, and instead rely on helper programs (or
libraries). But keeping PPP negotiations in one daemon is something I
believe in, just like ISDN signalling or L2TP negotiations.
Btw, last time I looked, L2TP is a horrendously broken protocol; don't
ever expect multilink to work over it until flow control is added back in
(sound of head banging against wall).
> OTOH, if your pppoe babylon code was part of the kernel code i would never
> have written mine ;-> (you should have open sourced sooner than you did)
I didn't own the rights to that code, hence I couldn't make that decision.
You should note that I've changed employers since that code was written.
> The architectural split between user space and kernel is very
> clean. It is *exactly* the way i have it minus the tty approach. I love it
> other than the one glitch that you are adding another PPP stack. Perhaps,
> you folks can contribute to the current Linux PPP stack if you think it
> has weaknesses.
It's my intention to merge it once I'm released from certain strings.
> > I'll just say that the tty subsystem sucks. You haven't tried writing a
> > driver for a DMA driven board with an ARM processor driving the DSPs that
> > does all of the PPP framing for you, but can also be a tty (yet it still
> > likes getting its data in chunks) -- flip buffers are a pain. The tty
> > code gets in your way big time, and sucks alot of performance out of the
> > system.
> >
>
> The channel stuff in the current 2.3 is not tty based. so no flip buffers
> to worry about. Infact if you look at my current implementation, i also
> dont worry about flip buffers.
These comments were more on the nature of the PPP & TTY subsystems in
general (not about PPPoE), since they're heavily dependant on each other,
I thought I'd mention it -- we need to modernize the tty driver interface.
I'm hoping other people out there will come forward and mention their
needs of such an interface, 'cause it has to be done sometime.
-ben
|