From owner-cvs-all@FreeBSD.ORG Thu Dec 9 21:51:30 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 419C216A4CE; Thu, 9 Dec 2004 21:51:30 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E41C943D49; Thu, 9 Dec 2004 21:51:29 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id iB9LpSWi032322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2004 13:51:29 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41B8CAE1.6040703@errno.com> Date: Thu, 09 Dec 2004 14:00:01 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <200412091641.iB9GflnD067866@repoman.freebsd.org> <20041209174457.GA82542@freefall.freebsd.org> <41B893D3.59939DEA@freebsd.org> <41B8BF81.2000701@errno.com> <20041209212512.GA946@cell.sick.ru> In-Reply-To: <20041209212512.GA946@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: "Christian S.J. Peron" cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet 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, 09 Dec 2004 21:51:30 -0000 Gleb Smirnoff wrote: > On Thu, Dec 09, 2004 at 01:11:29PM -0800, Sam Leffler wrote: > S> Chris and I had a discussion a while back about not adding code that > S> checks for the presence of optional functionality. Using tags was > S> intended to eliminate checks like this. Doing this sort of stuff can > S> cause an unmaintainable/unreadable mess. Unless you can show there is a > > I don't see reduced readability. I don't see reduced maintainability. Sigh. > > S> noticeable performance gain from doing this I think it's a bad idea. > S> Remember that m_tag_find already inlines the check for whether any tags > S> are present or not before doing the lookup. > > S> If tag lookup cost becomes an important consideration in writing code > S> then we need to address that basic functionality. > > Searching a list is always more expensive than comparing a pointer value. And your point? > > There may exist a tag from divert, from altq and any future tag. It is > obvious that this change gives performance gain, and it is obvious that > this gain is not noticeable. You are adding cost to the most common use case in order to satisfy your preferred operating conditions. The overhead for optional features must be weighed against the cost to users that do not need/use these features. I suspect the vast majority of users do not use altq, divert, or ipfw, pf, whatever. I'm sure someone will chime in and explain that everyone should run a packet filter on their machine (that Darren's schtick ? :)) but my point is that it is not obvious this is a win. > > Now I'm working on interaction between netgraph and ipfw. I'm going > to add a very similar tag lookup here. The vast majority of hosts > running ipfw do not use dummynet or netgraph facility. Why would they > look in every packet for tags that would never appear in any packet? I'm glad your working on this stuff but please don't lose sight that netgraph and ipfw are optional components and their operation should not weigh down the operation of a system w/o them. If the cost is minimal I've got no issue. But since you refuse to measure the cost and simply state "it's obviously no cost" I'm going to complain. I understand this is one memory compare, but adding one here, one there, and eventually it does add up. > > I'd like to remind you that in this thread you were against removal > of the very similar check before doing tag lookup: > > http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg22234.html True, but there are differences. The post you cite was about vlans and checking every packet that passes through a driver. That case was significantly more performance critical than yours. > > P.S. If you and Chris insist on reverting, I will do revert, but you didn't > made my opinion. > I never asked to revert; I am stating that I think this is a bad direction to go in. I removed all such checks a while back when I converted a lot of the old goo to use tags and at that time I MEASURED the overehead associated with the changes. Sam