On Sun, 2015-02-01 at 14:26 +0200, Michael S. Tsirkin wrote: > > When I run over the VPN, netperf thinks it sent 2½ times the amount of > > TX traffic. > > At some level, it's expected: netperf's manual actually says: > A UDP_STREAM test has no end-to-end flow control - UDP provides none and > neither does netperf. However, if you wish, you can configure netperf > with --enable-intervals=yes to enable the global command-line -b and -w > options to pace bursts of traffic onto the network.
True, but UDP is just a canary for other protocols here. We *should* be
able to keep track of the packets before they even leave the box, and
know that we haven't even managed to send them. Even if we know it's a
datagram protocol and it's potentially going to be dropped in transit
later.
Of course, now I'm looking closely at the path these packets take to
leave the box, it starts to offend me that they're being passed up to
userspace just to encrypt them (as DTLS or ESP) and then send them back
down to the kernel on a UDP socket. The kernel already knows how to
{en,de}crypt ESP, and do the sequence number checking on incoming
packets.
I'm wondering if we bypass userspace in that case somehow — let
userspace negotiate the encryption and connect the UDP socket, then just
pass the socket fd and the parameters to the kernel so that incoming
packets are decrypted and 'received' on the tun device, and outgoing
packets on the tun device are encrypted and sent out on the UDP socket.
The performance isn't too much of an issue for a VPN *client* in
practice, but we have a server implementation too which would probably
benefit quite well from such an offload facility.
If I were to look at such a thing, would it provoke screams of horror?
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
