LGTM

Should we try to account for a VLAN header here too?

Other than Mark's remark I think this looks good.

Other than not removing the pfvar.h include I'm happy with the pf changes, but please try to get someone to okay the addition in sys/time.h too.

Do we have measurements of what difference this makes?

The commit message needs to answer the 'why' question.
Why do we want this? We already have if_bridge, what does veb do that if_bridge does not?

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.