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?
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
