Re: [PATCH 1/2] ipv4: Improve the scaling of the ARP cache for multicast destinations.

[David Miller <davem@davemloft.net>]

From: Bob Gilligan <gilligan@aristanetworks.com>
Date: Thu, 30 Aug 2012 17:55:04 -0700

> The mapping from multicast IPv4 address to MAC address can just as
> easily be done at the time a packet is to be sent.  With this change,
> we maintain one ARP cache entry for each interface that has at least
> one multicast group member.  All routes to IPv4 multicast destinations
> via a particular interface use the same ARP cache entry.  This entry
> does not store the MAC address to use.  Instead, packets for multicast
> destinations go to a new output function that maps the destination
> IPv4 multicast address into the MAC address and forms the MAC header.

Doing an ARP MC mapping on every packet is much more expensive than
doing a copy of the hard header cache.

I do not believe the memory consumption issue you use to justify this
change is a real issue.

If you are talking to that many multicast groups actively, you do want
that many neighbour cache entries.  This is not different from talking
to nearly every IP address on a local /8 subnet.  You'll have a huge
number of neighbour table entries in that case as well.

If your the actual steady state number of active groups being spoken
to is smaller, you can tune the neighbour cache thresholds to collect
old less used entries more quickly.

And this today is trivial, since routes no longer hold a reference
to neighbour entries.  Therefore any neighbour entry whatsoever can
be immediately reclaimed at any moment.

I'm not fond of these patches, and adding yet more special cases to
the neighbour layer, and therefore will not apply them.