Re: Some performance measurements on the FreeBSD network stack

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