On 19.04.2012 22:34, K. Macy wrote: >>> This is indeed a big problem. I'm working (rough edges remain) on >>> changing the routing table locking to an rmlock (read-mostly) which >> > > This only helps if your flows aren't hitting the same rtentry. > Otherwise you still convoy on the lock for the rtentry itself to > increment and decrement the rtentry's reference count. The rtentry lock isn't obtained anymore. While the rmlock read lock is held on the rtable the relevant information like ifp and such is copied out. No later referencing possible. In the end any referencing of an rtentry would be forbidden and the rtentry lock can be removed. The second step can be optional though. >> i was wondering, is there a way (and/or any advantage) to use the >> fastforward code to look up the route for locally sourced packets ? >> > > If the number of peers is bounded then you can use the flowtable. Max > PPS is much higher bypassing routing lookup. However, it doesn't scale > to arbitrary flow numbers. In theory a rmlock-only lookup into a default-route only routing table would be faster than creating a flow table entry for every destination. It a matter of churn though. The flowtable isn't lockless in itself, is it? -- AndreReceived on Thu Apr 19 2012 - 19:11:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC