From owner-cvs-src@FreeBSD.ORG Fri Dec 10 11:16:33 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C390216A4D1 for ; Fri, 10 Dec 2004 11:16:33 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D89D43D5E for ; Fri, 10 Dec 2004 11:16:32 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 93823 invoked from network); 10 Dec 2004 11:06:08 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2004 11:06:08 -0000 Message-ID: <41B98594.A2FBC9E@freebsd.org> Date: Fri, 10 Dec 2004 12:16:36 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon 'corecode' Schubert References: <200412091641.iB9GflnD067866@repoman.freebsd.org> <41B8BF81.2000701@errno.com> <41B8EA66.4875E2D9@freebsd.org> <200412101103.27119.corecode@fs.ei.tum.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: src-committers@freebsd.org cc: cvs-src@freebsd.org cc: "Christian S.J. Peron" cc: cvs-all@freebsd.org cc: Gleb Smirnoff cc: Sam Leffler Subject: Re: cvs commit: src/sys/netinet ip_fw_pfil.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 11:16:34 -0000 Simon 'corecode' Schubert wrote: > > On Friday, 10. December 2004 01:14, Andre Oppermann wrote: > > > >>> Check that DUMMYNET_LOADED before seeking dummynet m_tag. > > > >>This change may be a mistake unless you can prove some significant > > > >>performance gain. > > > > Checking for DUMMYNET_LOADED is a simple pointer compare to NULL and > > > > doesn't add a memory write. Not a big difference for sure but not > > > > hurting either. > > > If tag lookup cost becomes an important consideration in writing code > > > then we need to address that basic functionality. > > Actually this is a good argument and reasoning and I buy into it. Not > > that is matter this much in this case but having nice and clean code > > wins big over time. I've spent and am still spending too much time > > cleaning up old BSD PDP-11 "optimizations" and other shortcuts. > > Forgive me if I'm way off here, I not experienced with the network stack as > you are. > > First of all I also think that this check here might be > over(micro)optimization. Nevertheless, if tags appear to be a (small) > performance hit, I conclude that there should be a fast way to check for the > (possible?) existance of a tag. So for example having a bit field signaling > the presence of the most important tags which are checked in the hot code > path might help, so is this really stupid[tm]? Please have a close look at sys/sys/mbuf.h; that should answer all outstanding questions for this case. -- Andre