I don't think it would be desirable for the kernel to handle rekeying, the socket should get sent back to userspace for that. That would probably require some wrangling, and it's certainly easier to do it in a good enough fashion rather than try to clean it up and get it upstreamed, but it's not impossible. I'm certainly guilty of not getting enough energy around upstreaming patches too, though.
> I don't think it would be desirable for the kernel to handle rekeying, the socket should get sent back to userspace for that. That would probably require some wrangling, and it's certainly easier to do it in a good enough fashion rather than try to clean it up and get it upstreamed, but it's not impossible.
Sure; I agree. I tried to address that under "It isn't really obvious how it would be cleaned up to be general enough to import, and it would be a ton of work with little payoff."
After all, you have to integrate with OpenSSL (or whatever) on the userspace side somehow too. And OpenSSL is contrib code, so we can't just hack it willy-nilly.
OpenSSL already has integration for Linux's similar kTLS support (bulk transmit encryption only; all other alerts, renegotiation etc punted back to userspace). If you wrote it to provide the same API then the OpenSSL support side would be easy.
https://github.com/openssl/openssl/blob/d6c3c1896cf3c0d69bc2...
ConcurrencyKit is imported and used for efficient read-mostly datastructures in FreeBSD 12, mostly in networking applications such as IP routing and link-level address caching (i.e., ARP in IPv4 Ethernet). It's also used in network interface drivers, HWPMC, TCP, and the linuxkpi emulation layer (to emulate RCU).
You might be interested in this blog post: http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-livene... and https://www.freebsd.org/releases/12.0R/relnotes.html .