| 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
| ||
|
Message-ID: <1370465535.24311.304.camel@edumazet-glaptop> 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
Powered by blists - more mailing lists