Network stack changes
Luigi Rizzo
rizzo at iet.unipi.it
Mon Sep 23 04:53:01 UTC 2013
On Mon, Sep 23, 2013 at 6:42 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi!
>
>
>
> On 22 September 2013 13:12, Alexander V. Chernikov <
> melifaro at yandex-team.ru> wrote:
>
>
>> I'm thinking the same way, but we're stuck with 'forwarding lookup' due
>> to problem with egress interface pointer, as I mention earlier. However it
>> is interesting to see how much it helps, regardless of locking.
>>
>> Currently I'm thinking that we should try to change radix to something
>> different (it seems that it can be checked fast) and see what happened.
>> Luigi's performance numbers for our radix are too awful, and there is a
>> patch implementing alternative trie:
>> http://info.iet.unipi.it/~**luigi/papers/20120601-dxr.pdf<http://info.iet.unipi.it/~luigi/papers/20120601-dxr.pdf>
>> http://www.nxlab.fer.hr/dxr/**stable_8_20120824.diff<http://www.nxlab.fer.hr/dxr/stable_8_20120824.diff>
>>
>>
> So, I can make educated guesses about why this is better for forwarding
> workloads. I'd like to characterize it though. So, what's it doing that's
> better? better locking? better caching behaviour? less memory lookups? etc.
>
>
locking affects scalability; but dxr and similar algorithms have much fewer
memory lookups, not to mention the huge memory footprint of
the freebsd radix tree code.
Anyways i'd really encourage you to read the dxr paper, it is short
and hopefully can give you a better idea of the details (and with data
supporting them) than these short notes.
cheers
luigi
More information about the freebsd-net
mailing list