cvs commit: src/sys/netinet ip_fw2.c

[Darren Reed]

On Tue, Dec 06, 2005 at 10:45:49AM +0000, Gleb Smirnoff wrote:
> glebius     2005-12-06 10:45:49 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/netinet          ip_fw2.c 
>   Log:
>     Optimize parallel processing of ipfw(4) rulesets eliminating the locking
>   of the radix lookup tables. Since several rnh_lookup() can run in
>   parallel on the same table, we can piggyback on the shared locking
>   provided by ipfw(4).

While I understand what you're doing here, it isn't the correct
way to approach this problem.  The lock macros for locking the
radix code are the ones that should be used here and are the ones
that should be relied on to properly protect the data in the radix
table, not ipfw locks.  If someone were to now change the radix
code in a way that depended upon the locking it currently has,
ipfw would get broken needlessly.  Whilst that kind of change isn't
likely to happen, it would never happen if ipfw used the right
locking interface for interaction with the radix code.

Given you're using a r/w lock and the radix code uses a mutex
(presumably put there by someone who studied this code?), how
can you be sure the results of your change are safe ?

Are you saying that the radix code can safely be wrapt up inside
of a r/w lock instead of a mutex ?

Why not change the LOCK macros for radix.[ch] if that is the case ?

Darren