netdev
[Top] [All Lists]

Re: [RFC] Yield in netlink_broadcast when congested

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC] Yield in netlink_broadcast when congested
From: Thomas Graf <tgraf@xxxxxxx>
Date: Sun, 17 Oct 2004 01:51:37 +0200
Cc: Pablo Neira <pablo@xxxxxxxxxxx>, hadi@xxxxxxxxxx, "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20041016113006.GA12843@xxxxxxxxxxxxxxxxxxx>
References: <20041016113006.GA12843@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* Herbert Xu <20041016113006.GA12843@xxxxxxxxxxxxxxxxxxx> 2004-10-16 21:30
> So here is my proposal: if we detect signs of impending congestion
> in netlink_broadcast(), and that we're in a sleepable context, then
> we yield().
> 
> This gives the receivers a chance to pull down the messages without
> having the sender spinning indefinitely.  I've tested it on my UP
> machine and it does resolve the problem for ip monitor.

Looks good.

Up to how many receivers does that work? We would still see the
effect if too many receivers are registered, right?

I haven't had the time to read through the previous conversion so
I don't know if this has come up so far but we could request an ACK
from each receiver an congest based on the following strategy:

SS := Last serial sent
SR := Last serial received
LL := Lower congestion limit to ignore short bursts
UL := Upper congestion limit to avoid infinite congestion:

Congestion map for (SS - SR)
0..LL: NOP
LL..UL: dp-congestion
UL..MAX: NOP

The biggest problem is that I don't know of any application
handling ACK requests properly yet.

Just a wild idea anyway, I'm not even sure whether it's worth
the effort.

<Prev in Thread] Current Thread [Next in Thread>