SEO

On Fri, 19 May 2006, joerg@britannica.bec.de wrote:

> For any setup which has a high throughput with an average number of states
> this would add a noticable overhead. For bigger state tables, but still
> long running connections, it can even trash the caches a lot. That makes
> it IMO less useful for the default code.

OK, you are probably right about this. Now when I took a second look into
the 3.9 code I came up with the following idea which keeps the performance
of the avare case practically identical to current one, but still removes
the big sweeps from high connection rate setups (This compeletely ignores
locks and process context vs. interrup handler caller issues, but just to
illustrate the basic idea):

The 3.9 (CVS 1.512) version of pf.c pf_purge_expired_states()
already takes the maxiumum number of operations to perform as an
argument. Currently it is called with
(pf_status.states /pf_default_rule.timeout[PFTM_INTERVAL]).

Now if we add call to this function with a small, probably configurable,
argument (typically 0-20) to pf_insert_state we keep up purging old state
entries while generating new ones. In cases with stable states never
expiring (and practically never coming up with new ones either), nothing
changes from the current way of doing things. At sites where the
connection creation rate is huge compared to the packet rate, the
PFTM_INTERVAL can be set in pf.conf to a large number and still the
purging done at insert_state can prevent the kernel running out of
memory.

--
Teemu J. Takanen
Product Security Manager, Tecnomen Messaging Services