Re: Route cache performance under stress

[Robert Olsson <Robert.Olsson@data.slu.se>]

David S. Miller writes:

 > I want to point out an error in such simulations.
 > 
 > It doesn't eliminate some of the most expensive part of the routing
 > cache, the 'dst' management.  All of that still happens even after
 > your patch.
 > 
 > A better simulation of a "pure slowpath" would be to move the DST
 > entry into the fib entries themselves.
 > 
 > That is a lot more work, but it would validate the various ideas and
 > claims being made.  For example, it would say for sure whether
 > eliminating the routing cache is a win or not for DoS traffic.

 Well it's true. But do we need too? From the profile we actually see the 
 'dst' management cost. Not much I would say and still we will need some 
 adminstration i.e refcounting even it we should remove the route hash.
 
c023c038 107340   33.143      fn_hash_lookup
c013154c 17399    5.37223     free_block
c0211364 16502    5.09527     __rt_hash_shrink
c01316e4 12854    3.96889     kmem_cache_alloc
c01b86dc 11719    3.61844     e1000_clean_rx_irq
c02033a0 11557    3.56842     alloc_skb
c0212330 11378    3.51315     ip_route_input_slow
c020cc98 9765     3.01511     eth_type_trans
c0208860 7986     2.46581     dst_alloc
c0216d98 7733     2.38769     ip_output
c021200c 6940     2.14284     rt_set_nexthop
c0213a9c 6331     1.9548      dst_free
c0126998 6272     1.93659     rcu_do_batch
c02035cc 6164     1.90324     skb_release_data
c02036c4 6068     1.8736      __kfree_skb
c01b8558 5532     1.7081      e1000_clean_tx_irq
c01b7678 4970     1.53457     e1000_xmit_frame

 From what I understand now removing the route hash is not a good idea. It's 
 seems we can control the hash pretty well and this even under very extreme 
 conditions.
 
 I think that people who is suggesting this thinks that we can achieve same 
 performance without it. I don't think we can. So question is should we tune
 routing to do 120 kpps regardless of input or have a performance span of 
 112-420 kpps (numbers from my tests). Where we most of the time are close
 to the higher limit?

 Anyway fib_lookup seems to be something to look into regardless of this 
 question.

 Cheers.

						--ro