Hi,

jamal wrote:

On Sun, 2004-09-19 at 22:58, Herbert Xu wrote:
 

quoted

AFAICT the problem Pablo is trying to solve is packet loss due to
netlink congestion.

There might actually be a problem with the kernel not waking up the
the user process when we tell it to.  It might even be a scheduling
problem.  But we'll need a test-case to assess that.

   

Agreed.
For a test i typically have something adding say 10K items (actions in
my case, but could be ipsec policies) and then try to dump them. On my
xeon i get an overrun after about 6K items are dumped.
 

yes, this is exactly what I've observed.

Here a link to the tool that I use to stress netlink sockets.

http://eurodev.net/~pablo/netlinkbench-unicast-1.0.tar.gz

We've set a webpage at the university: 
http://perso.ens-lyon.fr/laurent.lefevre/software/netlinkbench/ but the 
link to download the tool is broken, it will be up soon.

I've make also a version for broadcast sockets but it's basically a copy 
and paste of the unicast tool, I can also send you another link with it.

In nlbench-unicast.c there's a macro to set/unset MSG_DONTWAIT flag to 
make it hit my code or not.

regards,
Pablo