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

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