Hello,
>
> claudio had some questions about numbers used by the diff. some of the
> maths here is set up so that every pf state purge run is guaranteed to
> do a MINUMUM amount of work. by default pf is configured with a purge
> interfval of 10 seconds, bu the pf state purge processing runs ever
On Tue, Jun 07, 2022 at 04:58:24PM +1000, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for
David Gwynne [da...@gwynne.id.au] wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for too long.
>
I've be
Hello,
I like this change and I think this should go in as-is.
This is OK sashan@
I also think we should revisit a pf.conf(5) manpage where
'interval' (PFTM_INTERVAL) is described. It currently
reads as follows:
set timeout variable value
frag Seconds before an unassemble
On 2022/06/07 16:58, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for too long.
I'm runnin
the main change here is to move pf_purge out from under the kernel lock.
another part of the change is to limit the amount of work the state
purging does to avoid hogging a cpu too much, and to also avoid holding
NET_LOCK for too long.
the main part is acheived by using systqmp to run the purge t
