Hi Aleks,
On Mon, Sep 04, 2017 at 09:34:07AM +0200, Aleksandar Lazic wrote:
> Hi,
>
> Have anyone seen KTLS also?
>
> https://lwn.net/Articles/666509/
>
> https://netdevconf.org/1.2/papers/ktls.pdf
>
> looks pretty interesting.
As I already mentionned (I don't remember to whom), I really don't see *any*
benefit in this approach and only problems in fact. By the way, others have
attempted it in the past and failed.
The intended purpose is to save memory copies. But memory copies cost very
little compared to AES encryption, so the savings are very marginal, as the
graph shows. The reality is that in order to increase the performance by
only 5% :
- existing TLS application code will require modifications to be able to
use both openssl and ktls
- as new algorithms are deployed, you'll have to switch back to openssl
and disable kernel offloading for the time it takes to upgrade to a
new kernel. FWIW we're seeing people install openssl 1.0.2 or 1.1.0
on centos 7. This proves that userland moves faster than kernels. This
problem could slow down adoption of new algorithms by the way, which is
exactly what QUIC is fighting by moving all the TCP stack into the
browser :-(
- the data to be encrypted are now transferred to the kernel and visible
using strace. One could argue that it will help with debugging, but it
is also sometimes useful on some production systems to know that strace
remains a safe tool to use because you don't see clear text data.
- the application has less control over the TLS record size, which is
critical to page load time as it allows browsers to parse contents on
the fly without having to wait for a full transfer before decrypting.
So for me it's attacking a non-problem and will cause new problems. I'm
still not seeing any real benefit, I'm sorry. And you know that usually
I'm the one trying to push stuff into the kernel to make things faster.
It's just that *this* specific thing doesn't bring any obvious savings
to me.
Cheers,
Willy
