From owner-freebsd-hackers Thu Mar 7 22:24:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 89C2137B402; Thu, 7 Mar 2002 22:24:25 -0800 (PST) Received: from pool0036.cvx21-bradley.dialup.earthlink.net ([209.179.192.36] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16jDnj-0000k3-00; Thu, 07 Mar 2002 22:24:24 -0800 Message-ID: <3C885900.E1CB18C0@mindspring.com> Date: Thu, 07 Mar 2002 22:24:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fumerola Cc: Robert Watson , Julian Elischer , green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times References: <20020308033724.GZ803@elvis.mu.org> <20020308051520.GB803@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fumerola wrote: > i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene. ip_fw_chk should be obscene and not heard? 8-). > we're talking about an optimization that less then .1% of our userbase > will ever take advantage of v. a pessimization (additional argument in > the protocol handler + check of that arguement in the handler) in the > critical path of packet delivery in ALL cases (even kernels w/o ipfw). The check occurs only in the case that an in_pcblookup_hash() of the type needed was imminent. In the failure case, the call is made anyway. The comparative overhead relative to the actual hash lookup itself is miniscule. > it's just not worth it. 8-). The main performance path is going to be ip_flow fast forwarding. Actually, it's tempting to replace the src/src dst/dst hash with a src/src hash with a second level hash for the dst/dst lookup. THis would simplify the wildcard/non-wildcard case, as well as allowing a unification of the search space. If it were just the pcbhash, I think I'd go with a btree... or to make Alfred happy... a skiplist... ;^). > with ipfw cacheing the pcb lookup + credential check and w/o terry's > patch, the worst case would be a ruleset with any uid/gid rules: a pcb > lookup being done twice (once ever in ipfw, once in the protocol handler). > > that's really not so bad compared with the current behavior with uid/gid > rules where the lookup is done of a lot of times (as many uid/gid rules > you walk through before you match) in ipfw and once in the protocol > handler. This is the expensive part that I'd like to avoid. There are actually three hash lookups, if you have the firewall and ipflow code active. > > - The uid/gid code is broken for a number of important applications, > > including SSH forwarding, because SSHd binds the socket using a root > > credential rather than the user credential. [ ... ] > > i would like to make my cache have the proper credential(s) rather then > just cache the current socket credentials cr_uid, if that's wrong. Actually, I think the place to correct this is by allowing the fchown/fchmod on sockets to actually do the right thing... > please let me know privately just what exactly i should be comparing > against (or functions i should be using, if an API exists now) in -current > with the changes to credentials. > > when i mfc the cache, i'll just keep the current uid comparing behavior. The cache is a definite win; I think it should be more general, though. Luigi was talking about adding metadata to mbufs; you *could* tunnel the inp looked up through the metadata on the mbuf on which the data was dereferenced out of for the lookup in the first place. I think it's easier to just pass another parameter. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message