On Sun, 6 Feb 2000, Paul Mackerras wrote:
> - Forget the old (2.2) ppp driver, we'll backport the 2.3 driver to 2.2
> rather than doing major surgery to the 2.2 driver.
>
This looks like a lot of work to me. And doing this kind of thing on a
stable release might not be a very good idea either. In a few months (less
than 4?) we'll probably be moving to 2.4
> - At the moment, with the channels stuff, pppd needs to be able to have a
> fd to each channel which it can do read/write/poll/ioctl on, and the
> channel has to specify which ppp unit it is to be attached to when it is
> registered. I now think that we should do it a bit differently in order
> to minimize the amount of duplicated code in each channel.
>
> In order to be able to do multilink, pppd needs to be able to talk to each
> channel separately as well as to the ppp unit (which represents a bundle),
> and this is why pppd needs to be able to do read/write/poll on the channel.
> I plan to rearrange the code so that it will instead talk to the channel
> through an open instance of /dev/ppp. We'll make it so that when a channel
> registers itself, it gets given a channel number which can be passed to
> pppd. Pppd will open /dev/ppp and use an ioctl to connect that instance
> to the channel. It can then use another ioctl to connect that channel to
> a ppp unit.
>
Sounds like a good plan but quiet involved.
Mark would you please comment?
> This way, pppd doesn't have to know how to get hold of a file descriptor
> for talking directly to a channel, it just needs to know the channel
> number. We can then either have a separate program for the discovery or
> have a plugin to do the discovery. If we have a separate program, it
> just needs to tell pppd the channel number (there are several ways we can
> do this, e.g. via connect/disconnect scripts, or the discovery program
> invoking pppd, or the discovery program can talk to pppd through a pair of
> pipes or a socket). Probably there should be a UID associated with the
> channel to make sure I can't steal the channel you just set up.
Locking inside the kernel will help instead of UID i.e make the channel
grabbing atomic; if the channel is grabbed its state changes to "grabbed";
this could be also interpreted as a refcount; on close or detach it goes
back to "available" state.
> - I plan to pull out the async encapsulation stuff into a library so that
> other channels can use it too. Thus ppp_async.c should end up with very
> little in it other than stuff for implementing the line discipline and
> talking to the serial driver.
fantastic. I thought it was already a module by itself.
> - I am not so keen on the idea of having one process handling thousands of
> connections - don't poll and select get very inefficient if you have
> thousands of file descriptors? With that many fds, not only does the
> setup cost rise, but the poll/select will wait for a shorter time on
> average, so you pay the setup cost more often. On the other hand, having
> a thousand daemons means 8MB of kernel space gone just for the kernel
> stacks and process structures. We should maybe ask Alan Cox what the best
> compromise is.
>
I take it you are refering about the way the new pppd should handle this
increase in fds (you shouldnt have to worry about the pppoxs).
Wouldnt that be a single daemon?
For PPPOE running in server mode i see a lot of connections; so the usual
"scalable server" techniques apply. I would expect one pppoed to handle
all of them i.e pppd will only have to worry about the connection setup
and teardown and not any other event. Select is probably good enough; poll
will most likely be an overkill. Just off the top of my head.
> Certainly for moderate numbers of connections the process-per-connection
> model is good - if the daemon dies, you only lose one connection, and if
> you want to kill a connection, there is an identifiable process to send a
> signal to.
>
> I hope to spend a fair bit of the coming week on ppp hacking. :-)
>
I think other than the back porting i agree with everything you say.
My opinion is that we should have pppd separate from the pppoxds; in the
beggining until they stabilise, the pppoxds should be maintained
separately; i am agnostic to the fact it could be a plugin or
connect/disconnect.
cheers
jamal
|