On Sun, Sep 19, 2004 at 10:39:04PM -0400, jamal wrote:
>
> > 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~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
|