Claudio Jeker([email protected]) on 2019.12.31 11:44:07 +0100: > On Tue, Dec 31, 2019 at 11:16:37AM +0100, Martijn van Duren wrote: > > I'm on the fence about this. So if you feel strongly about this go > > ahead if it works. > > In some regard I agree but in this case I think it makes sense.
I think it even is useful if snmpd were more efficient in retrieving the data from pf. It just is a waste of cpu and bandwith to transfer these is you know in advance that you dont need them. > > I am however somewhat confused about your description. You say it > > times out, but considering it (by default) only retrieves 10 entries > > per packet it should return somewhat quick and not cause a timeout. > > If you want to move through it quicker you can increase the amount > > retrieved per request by setting -CrX where X can be any value. > > I reckon -Cr40 is a decent number. > > I doubt this will help. Looking at the code it seems that snmpd will fetch > the full pftable from the kernel for each request which is probably where > the inefficency and timeout happen. Also it does a linear search over > Florian's 300'000 addresses to pick up the next address. > > In short the pftable code and probably also the rest of the pf code in > snmpd is not built to scale. There is no caching, no fast lookups, no > smart paging implemented. This code needs major work to be usable. > > I think the diff by Florian is OK and should go in. +1 ok benno@
