From owner-freebsd-net Thu Mar 7 19:37:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 70B3237B402; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 415D2AE265; Thu, 7 Mar 2002 19:37:24 -0800 (PST) Date: Thu, 7 Mar 2002 19:37:24 -0800 From: Bill Fumerola To: Julian Elischer , Terry Lambert Cc: green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <20020308033724.GZ803@elvis.mu.org> References: <20020307092848.GX803@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020215 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote: > what would be even nicer is if ipfw found the cached entry and passed it > back to ip_input so it didn't need to :-) i think this entire idea of cacheing it in ip_input() is a bad idea, no offense terry. first, having a uid or gid rule in your ipfw ruleset (or even running ipfw) certainly isn't the common case. we're now going to bloat the ip_fw_chk() calls protocol handler calls to add an arguement that 99% of time is going to be NULL. then you have to bloat the protocol handlers to check if that pointer, that is NULL 99% of the time, isn't NULL. i just don't think that the gain in the edge case justifies the slowdown in the common case. the first person to say 'sysctl' or '#ifdef' gets to drink from the fire hose. second, the real travesty is that if you have N rules in ipfw that reference a uid or gid, you will do a pcb lookup on the same packet for each of those N rules until you match. the worst case scenario of having to do a lookup for each uid rule is what the charts in my previous post measure. terry asked in his post: "NB: Is there a particular reason Bill's changes haven't simply been committed?", the reason is that my cache of the pcb and uid was done in my compiledipfw code, not the mainline ipfw. its really not a straight port because of somethings that compiledipfw keeps state on before generating code (skiptos, mostly); ipfw would have to be more careful then the generated code needs to be. if brian feldman (the author of the ipfw uid/gid code) doesn't fix this out of embarassment first, i'll backport my cache into the main ipfw code. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org - my anger management counselor can beat up your self-affirmation therapist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message