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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
