SPI is a 32-bit semi-random value which would be quite hard to guess, unless somebody can sniff the traffic (but such case is a problem for all rfc1191-enabled protocols regardless of any anti-tampering checks).
To be 100% sure the packet belong to IPSEC tunnel (and that's how it works in ipsec module) is to use SPI and analyse ESP-Trailer and ESP-Authentication to confirm the originator of the packet is the machine we expect and data was not modified. Unfortunately, both of these are the last entries in IPSEC packet thus are not available in PTB response.

The longer I look into it the more I think the UDP part should be moved to the UDP code. Althoug it would be cleaner to have it here, due to limitations in RFC1191 payload length it is impossible to associate tunnel ID if knowing only UDP flow. I will handle it in a separate review and propose sth more generic.

Basic protection is guaranteed by IPSEC code. PMTUD NEEDFRAG msg contains a header of packet which caused the router to send such ICMP response. IPSEC handles PMTU change only if that header matches an existing tunnel.

Any objections for committing this after adding a hook to udp_userreq?

Good point. I removed all *input processing and left only *output check, which might be worth to have it in one place as we don't update mtu here anyway. Also pushed some changes to UDP ctlinput to match https://reviews.freebsd.org/D30992

That's a very good point, unfortunately I don't have a clear answer.
I'm aware of the problem with grep and this patch definitely not resolves it.

Yet another reincarnation of https://reviews.freebsd.org/rS302292 this time in peak_clear_sc
If no objections, I will commit this next week.

Closed by https://svnweb.freebsd.org/changeset/base/336128

Here is my two cents.

We'll handle the BE part.

Looks OK, we'll test it on our hardware.

I think we talked out all issues here.
I'll split this to separate patches and commit to the HEAD. Please let me know if you have any objections.

Actually, this is the only way to release resources by idling CPUs within the same SMT group - Linux does the same.
Sleep mode used here has the shortest wakeup delay, so the only performance hit is from saving and restoring context. However, it's still less complex than the one in cpu_switch.

Nice!

It SHOULD work on PowerNV as the code for cpuid swap is there, however I did not run much of testing, so I'd rather consider this as experimental/not-working. The CHRP platform has no such code, so there the BSP must be at CPU0.