On 06/09/2019 10:36, Hangbin Liu wrote: > 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 <k...@ka9q.net> > Signed-off-by: Hangbin Liu <liuhang...@gmail.com> > --- > net/ipv4/ipmr.c | 4 ++-- > net/ipv6/ip6mr.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) >
Please CC all interested parties who have reviewed/commented on previous versions. I'd also add a Suggested-by tag such as: Suggested-by: Eric Dumazet <eric.duma...@gmail.com> Looks good to me, thanks! Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>
