netdev - Re: Performance regression from routing cache removal?

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:	Wed, 05 Jun 2013 13:52:15 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Shawn Bohrer <sbohrer@...advisors.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Performance regression from routing cache removal?

On Wed, 2013-06-05 at 15:32 -0500, Shawn Bohrer wrote:

> Indeed it does.  So what are my options here?
> 
> 1) Use fewer multicast addresses.  This may not be possible since in
> some cases I don't control the incoming data/addresses.  I am running
> a test sending the same data over ~280 vs 350 and naturally it does
> appear to be better.
> 
> 2) Make that linear scan a hash lookup?  Are there any downsides or
> reasons not to do this?
> 

It can be easily done, with a threshold : 

Above say 4 multicast addresses in the mc_list, allocate a hash table
and populate it.

Nice thing is that this hash table could be dynamically reallocated,
instead of being of fixed size, as we would keep the mc_list as well.

> 3) ?

One idea would be to extend IP early demux, currently handling only TCP
sockets, to UDP sockets.

This would work if you have no more than one socket receiving traffic to
a particular address:port, and this would avoid IP fib/dst stuff, as the
socket would have a cache of the dst.

--
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