Date: Thu, 07 Mar 2002 22:24:00 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Fumerola <billf@elvis.mu.org> Cc: Robert Watson <rwatson@freebsd.org>, Julian Elischer <julian@elischer.org>, green@freebsd.org, net@freebsd.org, hackers@freebsd.org Subject: Re: in_pcblookup_hash() called multiple times Message-ID: <3C885900.E1CB18C0@mindspring.com> References: <20020308033724.GZ803@elvis.mu.org> <Pine.NEB.3.96L.1020307225650.32978J-100000@fledge.watson.org> <20020308051520.GB803@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C885900.E1CB18C0>