Re: passive references

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

   Date: Wed, 17 Feb 2016 13:56:02 +0900
   From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>

   Hi,

   On 2016/02/16 7:23, Taylor R Campbell wrote:
   > Thanks!  I'm a little confused, though: that patch series doesn't
   > apply cleanly when I extract it and pass it to `git am'.  Some of the
   > patches conflict with each other.

   Sorry, it includes some old patch. I updated it.

Much better!  These patches are much easier to review.  I have no more
time tonight (it is the wee hours of the morning in my time zone right
now!), but I can take a closer look and give some feedback later.

   > I would still like to see the independent functional changes in
   > separate patches -- especially USE_RADIX, because our radix tree code
   > is not safe for pserialize(9).  But I'll just make a few notes on the
   > unified patch for now.

   Sorry, it is my lack of consideration. The radix trees(encap_head[])
   and encaptab list must be updated atomically, so I thought it is
   required a exclusion like rwlock(9) if defined USE_RADIX. rwlock(9)
   is hated, so I considered alternate method, however it is being
   suspended, sorry.

rwlock(9) is a good start -- much easier to use safely, but it still
demonstrates the usage model.  (E.g., npf uses rwlocks and refcounts
for now, until we have a better alternative.)

   > So I would advise not to use !psref_held -- it is even more
   > questionable than !mutex_owned.

   I see. I don't use !psref_held.
   # I wanted !psref_held as I struggled against my psref_release()
   # leak bug...

That's understandable.  If I can't just write assertions, I try to
approach such bugs by making the code simpler until I understand it.

   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.