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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 02 Sep 2012 15:26:03 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Bob Gilligan <gilligan@...stanetworks.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] ipv4: Improve the scaling of the ARP cache for multicast
 destinations.

Le 31/08/2012 21:21, Bob Gilligan a écrit :
> On 8/30/12 6:06 PM, David Miller wrote:
>> From: Bob Gilligan<gilligan@...stanetworks.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html