Re: NPF tuning

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 15,  9:27pm, Mindaugas Rasiukevicius wrote:
} Egerváry Gergely <gergely%egervary.hu@localhost> wrote:
} >  > Turns out to be a proplib limitation:
} >  > https://nxr.netbsd.org/xref/src/common/lib/libprop/prop_kern.c#410
} >  > Christos bumped it in -current.
} > 
} > 128kB instead of 64kB... so... it will support ~240 rules instead of
} > ~120 or will my ruleset with ~500 rules fit in?
} > 
} > 64kB is a lot of space for only 120 rules. About 546 bytes for each
} > rule.
} 
} Yes, proplib is a awful [1].. I think there are quite a few developers
} who would like to replace it with something more sensible.
} 
} [1] https://mail-index.netbsd.org/tech-kern/2014/01/28/msg016489.html

     I just reread this thread.  Considering that only three or
four people expressed a negative opinion in the thread, my conclusion
is that the vast majority of developers are agnostic and only a
small handful of very out-spoken developers think it is awful (you
obviously being one of them).

     So, looking at your list and suggested replacement with libnv:

Why replace proplib with libnv?  Because contrary to proplib:
- It provides the equivalent functionality, but with twice less code.

     No it doesn't.  It doesn't offer the storage component.  Having
to use a seperate library for storage (which can be thought of as
slow transport) is a non-starter.  Thus libnv doesn't cut it.  I
would also like to see a simple example of the kernel code for
transporting nvlists.  proplib has simple to use functions for this
purpose.  It doesn't appear that libnv provides anything.

- It does not have insane reference counting like proplib (particularly,

     Gotta love the emotionally loaded terminology.

  asymmetric prop_dictionary_get() and prop_dictionary_set() routines).
- It does not use inefficient XML-like format.  It is binary.

     Upstream libprop (Apple) has a binary serialisation format.
We could just adapt it.  There's even code in the mailing list
archives for adding other serialisation formats.

- It does not add locking overhead which you do not need, see PR/44094.
- It does not have shared structures, e.g. proplib stores the keys in a
  global red-black tree (besides the fact that its implementation is
  duplicated, see PR/44090).  That means for example that the contention

     This has been fixed.

  on one subsystem can negatively affect another, unrelated, subsystem!

     Not sure about this.

- It does not abuse void * and therefore has more type safe code.
- It supports accumulated error handling (relevant for most use cases).
- Last but not least, it does not have awkward API naming, such as
  prop_data_create_data_nocopy() or prop_number_unsigned_integer_value().

     The API naming makes sense once you get used to it.

     For me, I would say that the biggest lack is schemas.  Anything
that doesn't address that is pointless.  After reading the manpage
for libnv my conclusion is that it doesn't provide any significant
advantage over proplib, certainly not enough to warrant the effort
of changing.

     I noticed that a lot of complaints have to do with the
implementation.  We have smart people.  We can fix that.

     I don't know if the proplib is the best, but I wouldn't call
it absolutely awful.  Note that I've used proplib in a couple of
projects so I feel reasonably qualified to talk about using it.

}-- End of excerpt from Mindaugas Rasiukevicius