SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-22-2008, 12:28 PM
| ||||
| ||||
 Re: PF State Expiration Model for Huge Amount of States On Fri, May 19, 2006 at 10:30:28AM +0300, Teemu Takanen wrote: > PF expires states in periodic sweeps in the state structure. > > I propose the following solution: > > PF state entries should be modified to include one more RB-tree entry, > used for state expiration. This tree would be primarily keyed with > pf_state_expire() return values (modified to return 0 instead of > time_second for instant expire). The tree would be secondarily keyed by > state ids to prevent duplicate keys. All places of PF code modifying > timeout or expire values should be changed to call update function for > this new tree. The problem with this approach is that any longer living connection has far more updates than actual expiring states. It should also be kept in mind that this adds a lot of cache trashing due to the constant tree updates. What exactly is your concern? As long as memory usage is not the limiting factor and you want to reduce only the sawchain affect, the following might be a better approach. Currently after a fixed timeout the whole table of all states, fragments and src nodes is processed. For this the corresponding full table is processed. Replace this with a number of linked list and one of them every second / half second whatever. This adds very low additional overhead (one or two pointers per state, a few more instructions for creation and removal of a state), but the runtime costs are not changed at all. This reduces the saws, but doesn't eliminate them. It might be enough though. Joerg      |
 |
« PF State Expiration Model for Huge Amount of States
|
Re: PF State Expiration Model for Huge Amount of States »
| Thread Tools | |
| Display Modes | |
Linear Mode
|
|
All times are GMT. The time now is 05:38 PM.
