On 19.04.2012 23:17, K. Macy wrote: >>> 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. > > Can you point me to a tree where you've made these changes? It's not in a public tree. I just did a 'svn up' and the recent pf and rtsocket changes created some conflicts. Have to solve them before posting. Timeframe (early) next week. >>>> 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? > > It is. In a steady state where the working set of peers fits in the > table it should be just a simple hash of the ip and then a lookup. Yes, but the lookup requires a lock? Or is every entry replicated to every CPU? So a number of concurrent CPU's sending to the same UDP destination would content on that lock? -- AndreReceived on Thu Apr 19 2012 - 19:26:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC