In D53697#1227856, @igoro wrote:

In D53697#1226388, @jhb wrote:

@igoro would you be able to test this on your workload (armv7) to ensure it still does the correct thing?

VM-based armv7 tests on my side passed. I believe it's enough as pfctl was unusable before the fix (after switching to Netlink).
It's up to @kp whether it needs additional run on actual armv7-based appliance.

The content looks good to me.

Do you have a specific OpenBSD patch you obtained this from?

Part of the issue here is that we've got layer 3 and ethernet anchors and it's possible for an anchor to exist in one but not the other. So a pfctl -sA -a foo can be valid for one but not the other. I don't immediately see a better way of handling that than to just not raise errors either.

Thanks. I’ll try to review this (and your other patch) in the next days.

In D53070#1213136, @mjg wrote:

In D53070#1212847, @kp wrote:

I do still want to murder this code, but we'll wait until armv7 finally dies, or dies enough.

one can consider reverting this to a state prior to introduction of per-cpu counters. that is, just have a var updated directly. this loses updates, but maybe it's good enough for armv7?

Thanks for catching that. I'm not sure how I missed it, but I'm glad I remembered you wrote it and would be a good person to copy on a review.

LGTM

LGTM, ship it.

In D52852#1208672, @zlei wrote:

I've ever considered this approach, but this adds too many headaches. Well I'd propose to use vlxan(4) + bridge(4) + epair(4) if the underlay network is in different VNET.

For example, how can the admin change the tunnel parameters ( vni / vxlanlocal / vxlanremote / ports ) when the vxlan(4) interface is vmoved to another VNET ?

In D52852#1207545, @glebius wrote:

if_vmove bites again? I'm fine with adding more kludges around this problem as long as we all agree that eventually this thing needs to be removed and interfaces shall be fully destroyed and fully instantiated in a different jail.