On Mon, Feb 17, 2014 at 03:21:53PM +0100, Henning Brauer wrote: > * Stuart Henderson <[email protected]> [2014-02-17 14:45]: > > Hmm. Well, I was assuming from the name and pfctl(8) description that > > it should be "state-limit", but actually it seems that is just used for > > max-src-states and this case just falls under "memory" which is not > > too descriptive. > > indeed. > > > I don't see a specific "do we exceed max-states" check, just a > > "pool_get failed when trying to get memory for a new state". > > yes, that's how it works. the limit is set as pool limit. > fairy tale: that comes from the oooooooooold days when kernel memory > management wasn't what it is today, but rather a pile of static poo. > back then, running a pool out of memory would panic the machine. > > > I wonder about adding a separate check to give better logging, > > though this is code that needs to run *fast*... > > a simple check at state creation time is ok. > > > The current use of PFRES_MAXSTATES particularly with pfctl's textual > > form "state-limit" is definitely a bit confusing. > > yup. > > the default of 10000 might be a bit small today as well. it's not like > a higher one would cost anything these days. 100k? >
How much memory are 10'000 states using these days? Would it be possible to auto tune these values somehow? One issue I have seen is that because of adaptive timeouts you can end up with failing connections without hitting the hard state limit. I think those connections will not show up in the stats (I could be wrong). -- :wq Claudio
