On Mon, Sep 20, 2004 at 02:31:32AM +0200, Pablo Neira wrote:
>
> >There is no point for the kernel to wait at all. For unicast sockets
> >used for sending commands to the kernel, you should never get overruns
> >if you are reading your responses correctly and have set the queue size
> >correctly.
>
> sure, not for commands. When I talk about netlink sockets, I'm not
> focused on commands because what they do currently is quite enough for
> them I think. I know that commands are the main application of netlink
> sockets but there are many others.
My message was in response to your problem a) which looks exactly like
a command.
> >>b) A module needs to send a lot of information from kernel space to user
> >>space, if buffer gets full quickly, buffer overruns and
> >>netlink_unicast/broadcast never wait, so they drop packets.
>
> In that case, netlink buffer will surely overrun, so those 300 messages
> will be drop because kernel didn't wait a bit. This is what happens now,
> I can reproduce this with my tool.
Well I see two solutions. You either extend the receive queue or tell the
kernel to stop sending. The second is not an option here because you'll
lose the packets anyway.
Getting the kernel to wait is NOT a solution. It's just another form of
extending the receive queue, albeit an ugly one.
But hang on a second, the kernel should've woken up your process after the
very first message. Why isn't that happening?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
|