Some performance measurements on the FreeBSD network stack
andre at freebsd.org
Thu Apr 19 21:26:14 UTC 2012
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?
More information about the freebsd-current