Re: [PATCH] Improve behaviour of Netlink Sockets

On Sun, Sep 19, 2004 at 10:39:04PM -0400, jamal wrote:

quoted

However, in the scenarios that's been cited so far I can't see how it can
work.  For example, in the ip_queue context, the kernel really doesn't
have any alternative to dropping the packet, right?

I havent paid a lot of attention to ip_queue workings. But something

Well the ip_queue thing is simply a pipe that redirects packets going
into netfilter to user space.  So we can't really stop that pipe when
there is congestion.

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.

that will get the kernel to backoff when a certain socket threshold gets
exceeded then get it going again when a below a low watermak. Dumps
already have markers stored in the callbacks, maybe something a long the
same line of thinking. You may have to tell user space "theres more
coming". Not sure how to achieve this, just brainstorming.
Essentially this is where the improvements over std overun signaling is,
IMO.

This might work.  But we really need to look at something concrete to
see what the implications are.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt