From owner-cvs-all@FreeBSD.ORG Thu Oct 21 13:31:21 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B621E16A4D2 for ; Thu, 21 Oct 2004 13:31:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCCFC43D4C for ; Thu, 21 Oct 2004 13:31:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 76926 invoked from network); 21 Oct 2004 13:29:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 13:29:58 -0000 Message-ID: <4177BA2F.66B1CD71@freebsd.org> Date: Thu, 21 Oct 2004 15:31:27 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov References: <200410192114.i9JLEvjQ001574@repoman.freebsd.org> <41758BF6.5020909@freebsd.org> <41758DF2.D3C1BD26@freebsd.org> <20041021071148.GA46126@ip.net.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Scott Long 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 13:31:22 -0000 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