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

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 31/08/2012 21:21, Bob Gilligan a écrit :
> On 8/30/12 6:06 PM, David Miller wrote:
>> 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.

My two cents:

Why do we need a per interface neighbor cache for multicast? Isn't the target MAC expected to be the 
same for a give target multicast IP address, whatever the egress interface?

Can't we store the target MAC for multicast address on a neighbor cache entry with a fake dev value 
meaning "multicast"?

Can't we detect the fact that the IP destination address is multicast and search only the neighbor 
cache entries that have this fake dev value, instead of the egress interface?

This should reduce memory consumption (not N-squared anymore) without significantly increasing the 
CPU usage.

Do I miss something?

	Nicolas.