Date: Thu, 7 Mar 2002 19:37:24 -0800 From: Bill Fumerola <billf@mu.org> To: Julian Elischer <julian@elischer.org>, Terry Lambert <tlambert2@mindspring.com> 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> In-Reply-To: <Pine.BSF.4.21.0203070351020.41354-100000@InterJet.elischer.org> References: <20020307092848.GX803@elvis.mu.org> <Pine.BSF.4.21.0203070351020.41354-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020308033724.GZ803>