Good, ship it ;)

That looks correct, but I don't quite follow the commit message. As far as I can tell nothing in userspace ever sends PF_ST_ID.

I suspect I left those out because nothing uses them, but we may as well add them to libpfctl anyway.

Given that we (Netgate certainly, and FreeBSD mostly too) no longer care about armv7 I wonder if we shouldn't back out the armv7 specific code from pf entirely at this point.

That test seems to fail for me with failed: 0 != 2 (0 != 2). The ping doesn't find a route:

I wonder if we shouldn't just remove these versions of the get_states functions altogether.

Approved.

Approved.

That looks sane, but I'd really like to have a test case for this as well.

Sorry, I don't take LLM generated code. I am unwilling to bear the copyright risk, unwilling to expend the addition effort required to review them and just generally unwilling to support that industry.
It's not applicable to the tests, but for pf itself it would also prevent me from sharing code with OpenBSD because they also do not take LLM generated patches.

In D59276#1360539, @markj wrote:

In D59276#1360076, @kp wrote:

That said, I find myself mostly running tests in bricoler these days, and it won't help there because that's a new single-use VM every time, without the profile information. (Though perhaps we could teach bricoler to import existing profile information from the host system?)

Do you ever use the freebsd-regression-test-suite-ci target? It does a few things on top of freebsd-regression-test-suite:

• it keeps track of results across successive runs, so you'll have persistent results for run #1, #2, ...
• after the test suite finishes, it'll rerun failed and broken tests in a new VM, without parallelism enabled, so that we can better detect flakiness
• it can send email summaries after the test run finishes

I've never used that, no. I don't really have a need for that, although I suppose the automatic re-running of failed tests is interesting.

That's an interesting idea.
Running the pf tests (at parallelism=4) that knocks the runtime down from 16 minutes to 10 minutes, which is pretty impressive.

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