On 9/2/12 6:26 AM, Nicolas de Pesloüan wrote:

Le 31/08/2012 21:21, Bob Gilligan a écrit :

quoted

On 8/30/12 6:06 PM, David Miller wrote:

quoted

From: Bob Gilligan<redacted>
Date: Thu, 30 Aug 2012 17:55:04 -0700

quoted

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?

Sounds like you are suggesting the converse of my proposed patch:  One
"special" Neighbor Cache Entry per multicast group instead of one per
interface.  Unfortunately, I don't think this will work.  Different MAC
types have different frame formats and different multicast address
mappings, so can't share a common neighbor cache entry.

Bob.

    Nicolas.