On Wed, Sep 22, 2004 at 04:48:05AM +0200, Pablo Neira wrote:
>
> b) I'm thinking about netlink sockets as a method to generate event
> notifications. My benchmark tool just want to emulate that N events
> happen in a *very* short period of time (worst case), that implies
> sending N messages. So, forget that my tool sends previously a message
> to generate those N messages.
That's what I thought you wanted too, something like ip_queue.
You've got to remember that for ip_queue netlink is inherently
*unreliable*. Your application must be able to cope with dropped
packets and recover in a sane way. The kernel makes it slightly
easier for you in that it'll tell you if messages have been dropped.
But in the end it's up to the application to deal with it.
The only knob that you can tweak is the receive queue length. You
might think that making the kernel wait/back off is going solve the
problem. But it's just another way of extending the receive queue
length.
> Jamal, you're getting an overrun dumping ipsec policies. If I'm not
> wrong, that tool is doing that as dump operation, but that this
> shouldn't happen by using dump. Am I missing something?
I've never seen any overruns with IPsec. Perhaps there is a bug
somewhere.
> I would like to have a way to send notifications via netlink sockets
> without losing congestion control ability, that is, without losing
> messages because of an overrun.
Congestion control similar to the way dumping works may work for you.
But you need to tell us more about what you're actually using this for.
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
|