From: David Miller <davem@davemloft.net>
To: liuhangbin@gmail.com
Cc: netdev@vger.kernel.org, karn@ka9q.net, sukumarg1973@gmail.com,
kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
eric.dumazet@gmail.com
Subject: Re: [PATCHv3 net-next] ipmr: remove hard code cache_resolve_queue_len limit
Date: Sat, 07 Sep 2019 17:49:42 +0200 (CEST) [thread overview]
Message-ID: <20190907.174942.662063905491373058.davem@davemloft.net> (raw)
In-Reply-To: <20190906073601.10525-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 6 Sep 2019 15:36:01 +0800
> This is a re-post of previous patch wrote by David Miller[1].
>
> Phil Karn reported[2] that on busy networks with lots of unresolved
> multicast routing entries, the creation of new multicast group routes
> can be extremely slow and unreliable.
>
> The reason is we hard-coded multicast route entries with unresolved source
> addresses(cache_resolve_queue_len) to 10. If some multicast route never
> resolves and the unresolved source addresses increased, there will
> be no ability to create new multicast route cache.
>
> To resolve this issue, we need either add a sysctl entry to make the
> cache_resolve_queue_len configurable, or just remove cache_resolve_queue_len
> limit directly, as we already have the socket receive queue limits of mrouted
> socket, pointed by David.
>
> From my side, I'd perfer to remove the cache_resolve_queue_len limit instead
> of creating two more(IPv4 and IPv6 version) sysctl entry.
>
> [1] https://lkml.org/lkml/2018/7/22/11
> [2] https://lkml.org/lkml/2018/7/21/343
>
> v3: instead of remove cache_resolve_queue_len totally, let's only remove
> the hard code limit when allocate the unresolved cache, as Eric Dumazet
> suggested, so we don't need to re-count it in other places.
>
> v2: hold the mfc_unres_lock while walking the unresolved list in
> queue_count(), as Nikolay Aleksandrov remind.
>
> Reported-by: Phil Karn <karn@ka9q.net>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied to net-next.
prev parent reply other threads:[~2019-09-07 15:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 8:43 [PATCH net] ipmr: remove cache_resolve_queue_len Hangbin Liu
2019-09-03 9:15 ` Nikolay Aleksandrov
2019-09-03 12:55 ` Hangbin Liu
2019-09-03 13:18 ` Nikolay Aleksandrov
2019-09-04 3:34 ` [PATCHv2 net-next] " Hangbin Liu
2019-09-04 7:50 ` Eric Dumazet
2019-09-05 3:37 ` Hangbin Liu
2019-09-06 7:36 ` [PATCHv3 net-next] ipmr: remove hard code cache_resolve_queue_len limit Hangbin Liu
2019-09-06 10:08 ` Nikolay Aleksandrov
2019-09-07 15:49 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190907.174942.662063905491373058.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=karn@ka9q.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sukumarg1973@gmail.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).