Date: Tue, 19 Oct 2004 23:58:10 +0200 From: Andre Oppermann <andre@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: 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 Message-ID: <41758DF2.D3C1BD26@freebsd.org> References: <200410192114.i9JLEvjQ001574@repoman.freebsd.org> <41758BF6.5020909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41758DF2.D3C1BD26>