[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1483983850.5846.4.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Mon, 09 Jan 2017 09:44:10 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: netdev@...r.kernel.org, xiyou.wangcong@...il.com
Subject: Re: [net-next PATCH 2/3] net: reduce cycles spend on ICMP replies
that gets rate limited
On Mon, 2017-01-09 at 16:04 +0100, Jesper Dangaard Brouer wrote:
> This patch split the global and per (inet)peer ICMP-reply limiter
> code, and moves the global limit check to earlier in the packet
> processing path. Thus, avoid spending cycles on ICMP replies that
> gets limited/suppressed anyhow.
>
> The global ICMP rate limiter icmp_global_allow() is a good solution,
> it just happens too late in the process. The kernel goes through the
> full route lookup (return path) for the ICMP message, before taking
> the rate limit decision of not sending the ICMP reply.
>
> Details: The kernels global rate limiter for ICMP messages got added
> in commit 4cdf507d5452 ("icmp: add a global rate limitation"). It is
> a token bucket limiter with a global lock. It brilliantly avoids
> locking congestion by only updating when 20ms (HZ/50) were elapsed. It
> can then avoids taking lock when credit is exhausted (when under
> pressure) and time constraint for refill is not yet meet.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> ---
Acked-by: Eric Dumazet <edumazet@...gle.com>
Powered by blists - more mailing lists