I think the patch is fine now, but I would like to see the flame graphs anyway, so we're sure this does what we think it does.

I'm also struggling to make sense of the baseline flame graph. It seems to be spending a lot of time removing interfaces (5% of samples in pf_kkif_free()!) and I don't see any calls to pf_test(), which we should see if we were handling traffic.
Maybe the address decoding went wrong, because those stacks just look wrong.

It'd be good to turn those failing rules into a test case so we notice the next time I screw up.

Thanks for the fix.

LGTM

Add IFT_PFSYNC comment.

In D58560#1344488, @paige_paige.bio wrote:

fixing a couple of errors where I used xo_warn to replace calls to Perror by changing the calls back to Perror instead of xo_warn

I'll give Gleb a few more days to take another look and then I'll commit the entire series.
Thanks for the fix!

That looks pretty good to me, but I'd like to give Gleb some time to look as well. He's a lot more familiar with unmapped buffers than I am.

In D57851#1327103, @glebius wrote:

In D57851#1327098, @kp wrote:

Do you happen to know of a way to get an interface (struct ifnet) without AF_INET6? I used to use pflog0 for this, and now clearly can't any more. (The test for PR 288263 does that.)
Ideally I'd like to not remove the test, but without such an interface there's no point to it.

The whole point of the change, that now (after pfsync0 de-ifnetting) you can assert that any interface has IPv6 context. Lots of checks for that in netinet6 go away.

Remove epoch cleanup.
Update failing test case to use pfsync0 iso. pflog0 (for now).

mtx -> sx

Do you happen to know of a way to get an interface (struct ifnet) without AF_INET6? I used to use pflog0 for this, and now clearly can't any more. (The test for PR 288263 does that.)
Ideally I'd like to not remove the test, but without such an interface there's no point to it.

• locking fixes
• man page improvement
• fix pflogd to not look for a network interface
• have /etc/rc.d/pflogd create extra log devices if required

In D57851#1326392, @glebius wrote:

My only concern is racyness of sysctl vs sysctl. The node and proc are marked CTLFLAG_MPSAFE, so they can execute in parallel. bpf_attach() doesn't have protection against duplicates, so we will leak one.

Ah, yeah, that's an issue.
I could remove the MPSAFE, but we probably don't want to rely on Giant, so that's not great either.