Ben,
I like the architectural approach you took.
My comments below:
On Mon, 31 Jan 2000, Ben LaHaise wrote:
> Hey folks,
>
> Sorry if I've messed up the attribution of things, but I'm replying off of
> text copied from a web page since I'm not on the sparclinux-cvs
> list. I've added netdev to the cc list since that seems more appropriate
> coverage.
>
> jamal sayth:
>
> > On Mon, 31 Jan 2000, Andi Kleen wrote:
>
> > > Sorry for the confusion. There seems to be some inflation of PPPoE
> > > clients on linux at the moment (The Spellcaster guys apparently
> > > released another one with their PPP code, there are various user space
> > > versions floating around etc.)
>
> > The spellcaster one requires a replacement of the PPP stack in the
> > kernel as well.
>
> This is a good thing! =) I wrote that pppoe code as a quick hack one
> night after looking at the userspace implementations... It does the
> discovery in userspace, then does a 'dial' with the target MAC address and
> session id.
> That PPP stack is the way it is mostly because it wasn't
> being merged at the time it was being developed, so it couldn't patch
> anything else in the kernel and it had to run across 2.0/2.2/2.3.
Fair, you folks have customers to take care of. Linux on the other hand
has no loyalty to backward compatibility. Thats one thing that makes it
tick i guess ;->
> If I
> were to do any work on it now, I'd make it use a PPP socket instead of the
> charater device. The biggest benefit of the code is that it handles all
> PPP connections in a single daemon, so it requires a lot less from a
> system than using pppd. The multilink code is also well abused, and
> performs well against just about everything out there if the underlying
> device gives sufficient back pressure on transmit.
>
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.
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.
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)
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.
My understanding is you guys have a very good MPPP. I am no expert in that
area to comment however.
> Suffice it to say that I wouldn't expect to see the Babylon code merged as
> is, but there are useful bits and ideas in it.
>
true.
> > > The problem with jamal's 2.3 code is that it doesn't use the ppp
> > > channel support in 2.3 yet, it still runs over a line discipline with
> > > the tty PPP like the 2.2 version. I think porting it to ppp channel
> > > would be straight forward and jamal planned this anyways very soon.
>
> > It is straight forward. I have been hesitant doing so because i am
> > trying to be a minimalist. I have asked Paul Mackerras (Cced in this
> > mail) if i could make some small changes to remove what i think is a
> > small limitation to the Channel stuff and make it more generic. This way
> > we dont have to modify it for PPP over UDP(L2TP), PPP over ATM
> > etc. Paul will hopefully give me the green light. My secondary goal is
> > to get speed. And so if it turns the current tty design is faster than
> > the channel mode, then i'd rather stick to the tty mode.
>
> 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.
cheers,
jamal
|