cvs commit: src/sys/net pfil.c pfil.h src/sys/netinet ip_fastfwd.c ip_fw2.c ip_input.c ip_output.c src/sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c

John Baldwin jhb at freebsd.org
Thu Feb 2 09:33:54 PST 2006


On Wednesday 01 February 2006 22:13, Christian S.J. Peron wrote:
> csjp        2006-02-02 03:13:16 UTC
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/net              pfil.c pfil.h
>     sys/netinet          ip_fastfwd.c ip_fw2.c ip_input.c
>                          ip_output.c
>     sys/netinet6         ip6_forward.c ip6_input.c ip6_output.c
>   Log:
>   Somewhat re-factor the read/write locking mechanism associated with the
> packet filtering mechanisms to use the new rwlock(9) locking API:
>
>   - Drop the variables stored in the phil_head structure which were
> specific to conditions and the home rolled read/write locking mechanism.
>   - Drop some includes which were used for condition variables
>   - Drop the inline functions, and convert them to macros. Also, move these
>     macros into pfil.h
>   - Move pfil list locking macros intp phil.h as well
>   - Rename ph_busy_count to ph_nhooks. This variable will represent the
> number of IN/OUT hooks registered with the pfil head structure
>   - Define PFIL_HOOKED macro which evaluates to true if there are any
>     hooks to be ran by pfil_run_hooks
>   - In the IP/IP6 stacks, change the ph_busy_count comparison to use the
> new PFIL_HOOKED macro.
>   - Drop optimization in pfil_run_hooks which checks to see if there are
> any hooks to be ran, and returns if not. This check is already performed by
> the IP stacks when they call:
>
>           if (!PFIL_HOOKED(ph))
>                   goto skip_hooks;
>
>   - Drop in assertion which makes sure that the number of hooks never drops
>     below 0 for good measure. This in theory should never happen, and if it
>     does than there are problems somewhere
>   - Drop special logic around PFIL_WAITOK because rw_wlock(9) does not
> sleep - Drop variables which support home rolled read/write locking
> mechanism from the IPFW firewall chain structure.
>   - Swap out the read/write firewall chain lock internal to use the
> rwlock(9) API instead of our home rolled version
>   - Convert the inlined functions to macros
>
>   Reviewed by:    mlaier, andre, glebius
>   Thanks to:      jhb for the new locking API

Do the new locks perform better in any benchmarks than the previous version of 
what you were doing?

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the cvs-all mailing list