Re: passive references

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

Thank you for comments.

On 2016/02/17 16:46, Taylor R Campbell wrote:
>    BTW, I would design another(not radix tree) solution to fix the
>    scaling issue of many encap interfaces in the future work.
>    Does anyone have the solution to fix the scaling issue?
> 
> rmind@ has been working on a lockless radix tree data structure:
> <https://github.com/rmind/masstree>.  It's not yet finished, but once
> finished it will probably be incorporated into npf, to replace the
> current hash table of rwlocked binary trees.
> 
> In this case, we don't need something lockless -- it is OK for updates
> to be expensive, because changes to the tunnel configuration (writers)
> happen much less often than processing of packets (readers).
> 
> But we're getting ahead of ourselves.  The first performance issue
> with large numbers of tunnels, I expect, is the linear search for a
> matching tunnel, even when we have a radix tree.  To fix that, we may
> need to identify the semantics that all the applications of ip_encap
> require.

I'm sorry to misinform. As you indicated, the first performance issue
is linear search. In my measurement of gif(4) throughput, linear search
with using radix tree is much faster than linear search without radix
tree. So, I have thought using radix tree is a solution of the whole
ip_encap performance issue.

I agree it is required to identify the applications of ip_encap. I think
OpenBSD can be helpful. OpenBSD does not have ip_encap, however implement
gif and mroute.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>