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]

Ruslan Ermilov wrote:
> 
> On Tue, Oct 19, 2004 at 11:58:10PM +0200, Andre Oppermann wrote:
> > Scott Long wrote:
> [...]
> > > 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.
> >
> Err.  divert(4) sockets can also be accessed through the ng_ksocket(4)
> interface, in which case no userland-kernel copying takes place.  So
> the performance does matter.

Yes, you are correct.

Performance does not suffer from calling divert_input() through a function
pointer.  It takes four more instructions than calling it directly.  Half
of the network stack is going through function pointers and all of netgraph
is going through function pointers.  In all cases for each packet.  Going
through function pointers does not have any performance impact whatsoever
I was able to measure.  Granted, I haven't profiled it at the instruction
level.

I hope we can settle this matter now.  My original answer to Scott was
badly phrased.

-- 
Andre