move pf_purge out from under the kernel lock and avoid the hogging cpu
authordlg <dlg@openbsd.org>
Mon, 7 Nov 2022 12:56:38 +0000 (12:56 +0000)
committerdlg <dlg@openbsd.org>
Mon, 7 Nov 2022 12:56:38 +0000 (12:56 +0000)
commit22b63e6173746a6e967b6ce430f1f0bfd6a9db13
tree5c60d1f7757ad2fe649b48edacda3c5fcc9c6d2e
parentede3ef15bab0e916ab9dd4200b55f45a65abd6c1
move pf_purge out from under the kernel lock and avoid the hogging cpu

this also avoids holding NET_LOCK too long.

the main change is done by running the purge tasks in systqmp instead
of systq. the pf state list was recently reworked so iteration over
the state can be done without blocking insertions.

however, scanning a lot of states can still take a lot of time, so
this also makes the state list scanner yield if it has spent too
much time running.

the other purge tasks for source nodes, rules, and fragments have
been moved to their own timeout/task pair to simplify the time
accounting.

in my environment, before this change pf purges often took 10 to
50ms. the softclock thread runs next to it often took a similar
amount of time, presumably because they ended up spinning waiting
for each other. after this change the pf_purges are more like 6 to
12ms, and dont block softclock. most of the variability in the runs
now seems to come from contention on the net lock.

tested by me sthen@ chris@
ok sashan@ kn@ claudio@
sys/net/pf.c
sys/net/pf_ioctl.c
sys/net/pfvar.h
sys/net/pfvar_priv.h