fridex
commented
8 years ago ad 1) Yes, this should be dropped for sure. It also limits using kernel_sendpage() (https://github.com/ktls/af_ktls/issues/22 and https://github.com/ktls/af_ktls/commit/0fbc8d145d5f12490e1a51627b9cef7a3e6b8b6b)
ad 2) Applicable only for data records I suppose. However this will limit switching from OpenSSL, GnuTLS or another TLS lib. Once AF_KTLS socket will be instantiated, switching back to the lib will be possible only if there is some error during decryption or non-data record. If we do not introduce a mechanism for explicitly switching this off. Do we want it?
ad 3) Sounds good to me.
djwatson
nmav
Met with a couple netdev kernel guys (therbert, hannes, alexei) to discuss buffer management in ktls. Consensus was roughly:
1) Preallocated send/recv buffers per-socket aren't going to work, would be too much memory for large numbers of sockets. Need to allocate them lazily as we need to decode/encode. Alternatively, if we aren't pre-emptable, they could possibly be preallocated per-cpu as an optimization.
2) When the tcp socket has data ready, it needs to be pulled off the socket and stored the ktls. Otherwise a tcp socket with a receive buffer size of 4k, and being sent a larger TLS message, would not result in forward progress. There are also other reasons this needs to happen, like out of order receives in tcp interacting in interesting ways with the receive buffer size, that are also fixed by moving the sk_buffs to being owned by ktls instead. KCM already does a version of this.
3) Output buffers should probably be stored as sk_buffs on the socket, and not scattergather lists. This would facilitate passing ktls sockets to other kernel things (KCM), as well as supporting multiple message decode by respecting receive buffer sizes on ktls easily.