[Top] [All Lists]

Re: netlink drops messages.

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: netlink drops messages.
From: Andi Kleen <ak@xxxxxx>
Date: Thu, 18 Jan 2001 12:59:36 +0100
Cc: Werner Almesberger <Werner.Almesberger@xxxxxxx>, "James R. Leu" <jleu@xxxxxxxxxxxxxx>, kuznet@xxxxxxxxxxxxx, gleb@xxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <Pine.GSO.4.30.0101170744100.20342-100000@xxxxxxxxxxxxxxxx>; from hadi@xxxxxxxxxx on Wed, Jan 17, 2001 at 02:33:24PM +0100
References: <20010117122413.B18286@xxxxxxxxxxxxxxx> <Pine.GSO.4.30.0101170744100.20342-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
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. 


<Prev in Thread] Current Thread [Next in Thread>