On Wed, Jan 17, 2001 at 02:33:24PM +0100, jamal wrote:
> > The question here is of course if the entire communication model
> > is appropriate. An alternative approach could be to just record
> > that a notification is needed, wake the reader(s), and generate
> > the actual message in response to the recvmsg call. This way,
> > one could still pretend to user space that we have a simple
> > message-based notification system, while underneath, we happily
> > compress notifications.
> > Note that this wouldn't work well in all cases. E.g. if you have
> > lots of routes coming and going (and not coming back), you can't
> > compress notifications. Of course, netlink may be the least of
> > your worries in such a situation ...
> This is the classical problem Alexey was pointing to. Unsolvable, unless
> you have infinite memory in place.
Or you hack the kernel to directly update a shared memory with the needed
information with appropiate locking. Then there is no buffer to overflow,
at worst you could get some problems with the locks in overload cases.
I guess the router vendors who want to use Linux as a base could certainly
do that, the changes are not very complicated.
For a general linux interface it would be serious overkill though.
> The idea of compressed notifications (update "queues") in the kernel is
> beggining to look sane to me. But even for that you need to draw a line
> somewhere. And it is only useful if you are really interested in the
> sequence of states some entity has gone through. I suspect mostly you
> will be interested in knowing the state _current_ as opposed to "what
> happened? how did you get here? " kind of thing.
I suspect it first needs someone to show that it can get a real problem in a
real world case and cannot get solved there by reserving a few MB for the queue.
("Premature optimization is the root of all evil...")
I suspect if someone is really seriously expecting to handle hundreds of
interface up/down per seconds they would opt for shared memory. For routes
you do not even need kernel support, because you can do that privately with
the routing daemon.