Hi Willy, Willy Tarreau wrote on 05.09.2017:
> 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. Thank you for the detailed answer. I think that for some use cases could the solution fit, let's see how this feature will evolve. > Cheers, > Willy -- Best Regards Aleks
