cvs commit: src/sys/modules/ipdivert Makefile src/sys/netinetin_proto.c ip_divert.c ip_divert.h ip_fw2.c ip_fw_pfil.c

[Andre Oppermann]

Scott Long wrote:
> 
> Andre Oppermann wrote:
> > andre       2004-10-19 21:14:57 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     sys/netinet          in_proto.c ip_divert.c ip_divert.h
> >                          ip_fw2.c ip_fw_pfil.c
> >   Added files:
> >     sys/modules/ipdivert Makefile
> >   Log:
> >   Convert IPDIVERT into a loadable module.  This makes use of the dynamic loadability
> >   of protocols.  The call to divert_packet() is done through a function pointer.  All
> >   semantics of IPDIVERT remain intact.  If IPDIVERT is not loaded ipfw will refuse to
> >   install divert rules and  natd will complain about 'protocol not supported'.  Once
> >   it is loaded both will work and accept rules and open the divert socket.  The module
> >   can only be unloaded if no divert sockets are open.  It does not close any divert
> >   sockets when an unload is requested but will return EBUSY instead.
> >
> >   Revision  Changes    Path
> >   1.1       +8 -0      src/sys/modules/ipdivert/Makefile (new)
> >   1.75      +0 -13     src/sys/netinet/in_proto.c
> >   1.101     +67 -8     src/sys/netinet/ip_divert.c
> >   1.4       +10 -4     src/sys/netinet/ip_divert.h
> >   1.82      +2 -4      src/sys/netinet/ip_fw2.c
> >   1.11      +13 -8     src/sys/netinet/ip_fw_pfil.c
> 
> This is interesting.  Have you measured performance/latency with this
> new scheme?  Is it still possible to compile IPDIVERT into the kernel
> and avoid the indirect calls?

IPDIVERT can hardly be called a performance/latency critical path.  The
entire copyout of the packet to userland for nat'ing and copyin again
make the function pointer indirection such a small factor that it doesn't
make any difference whatsoever.

ipfw used to be called through function pointers until I converted it to
use pfil_hooks.  But even there we go though function pointers for every
packet.  The same is true for the entire ip_protox[] system and the whole
socket layer going through protosw[].

-- 
Andre