You may be interested in this: https://techcommunity.microsoft.com/t5/networking-blog/makin.... The gist is that yes QUIC has higher CPU usage but all OS platforms are investing in UDP hardware offloads and optimizations to level the playing field. While the only IETF standard that will come out is HTTP/3, our implementation MsQuic powers both HTTP/3 and SMB proving the general purpose nature of the transport. We are not there yet in terms of an application that's only powered by QUIC because UDP reachability is not 100%, so you need a fallback. Most apps will either use HTTP/3 and fallback to HTTP/2 or use QUIC directly and have to fall back to secure L7 over TCP.
For UDP, Linux supports GSO and GRO, allowing applications to send and receive "super"-packets which are split up and reassembled by the kernel or NIC, depending on what's available. Whether or not QUIC implementations utilize it, I'm not sure.
I may be wrong, but I believe someone explained to me a while back that one of the points of QUIc was that it was meant to be implemented purely in software as opposed to hardware.
Maybe QUIC would also mean the CPU working harder, but I'm not really sure.
I would be nice to have a thoughtful conversation about the security implication of QUIC: Wikipedia says packets are encrypted individually.
I'm also curious: is QUIC exclusively aimed towards HTTP2 or can it be used for real time applications, like real time gaming or video conferencing?