Re: Performance regression from routing cache removal?

[Eric Dumazet <eric.dumazet@gmail.com>]

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.