In released version, Kernel TLS never be used.

minio.New incorrect setting on Kernel TLS

Should we provide precompiled packages for Kernel TLS?

Kernel TLS package will auto try modprobe tls on Linux.

kernel TLS was added that whoever is testing this knows what they are doing, we are not building it on purpose for now to avoid confusion.

kernel TLS was added that whoever is testing this knows what they are doing, we are not building it on purpose for now to avoid confusion.

we will add k-tls support as a separate binary perhaps in time when we get to it, for now it was used internally for benchmarking.

PTAL the linter errors when you get time. Thank you for the PR.

PTAL the linter errors when you get time. Thank you for the PR.

Tomorrow, Thanks

@rbqvq Thanks for your awesome work! This was mainly added for experimentation - and to evaluate for use in our server. I don't believe anyone has had a chance to test it yet. Adding it to warp seemed like a erasonable canary.

Is it completely unfeasible to make this feature work as a co-compiled option? In both servers and clients we would like this to be a software opt-in, with seamless fallback if possible. We try very, very hard to never build feature specific binaries, since it adds complexity for the user and support for us. As such, we would like to have the option to opt-in to the feature on existing binaries, if we identify that TLS is a bottleneck.

Just asking because I didn't understand the reason for having it a compile-time option.

@rbqvq Thanks for your awesome work! This was mainly added for experimentation - and to evaluate for use in our server. I don't believe anyone has had a chance to test it yet. Adding it to warp seemed like a erasonable canary.

Is it completely unfeasible to make this feature work as a co-compiled option? In both servers and clients we would like this to be a software opt-in, with seamless fallback if possible. We try very, very hard to never build feature specific binaries, since it adds complexity for the user and support for us. As such, we would like to have the option to opt-in to the feature on existing binaries, if we identify that TLS is a bottleneck.

Just asking because I didn't understand the reason for having it a compile-time option.

Before recently commit, convert tls.ConnectionState use reflect to full convert (include unexported fields).
In recently commit, I use safe convert, and move reflect convert to FullCompatible

I think its no problem, go.mod protected the version.

But I can't confirm if newer golang version will has some compatible issue.

Ofcourse, It will not affect the non-ktls part.

I will update this PR later.

v2 changes (TODO):

• Remove build flag
• If http2 not enable, directly use http.Client (No type convert to improve performance)
• Changes 0-RTT to a flag (not enabled by default)

I have a question, Can I remove -ktls flag?

I perfer use -ktls-tx and -ktls-rx

And should we throw a new Error if ktls not setup successfully instead of fallback to software implement

Can I remove -ktls flag? I prefer use -ktls-tx and -ktls-rx

You are welcome to either hide (use Hidden: true) or remove it temporarily if it doesn't work.

I don't see any upsides from separating rx/tx, so that is not the UX we are looking for, as it just adds complexity.

As a side note, http/2 is not a huge priority - as we generally see more problems and less performance (same for http/3), but of course nice to have.

This is a performance testing tool

Expose all options to the user so they can control variables for testing

My comment on the proposal for crypto/tls to support Kernel TLS

One more thing.

Here is test result with iperf3 using this package.

TLS 1.3 CHACHA20
Linux 6.13 (splice)
SW (4.69 Gbps) > kTLS TX (4.65 Gbps) > kTLS RX (3.98 Gbps) > kTLS Both (3.88 Gbps)
FreeBSD 14 (no splice)
SW (3.05 Gbps) > kTLS RX (1.89 Gbps) > kTLS TX (1.71 Gbps) > kTLS Both (935 Mbps)
It seems that throughput is not as good as software implementation, even with zerocopy.

It is recommended that the option be given to the user rather than being turned on by default.

Kernel TLS will cause performance regression, especially RX offload
I only enable TX offload for my own projects
It would be a better choice to expose it to user control

I have reworked the PR and now the commit message contains the full description

Please review, Thanks

Please do not squash the commit, as it contains other fixes

kernel TLS was added that whoever is testing this knows what they are doing, we are not building it on purpose for now to avoid confusion.

we will add k-tls support as a separate binary perhaps in time when we get to it, for now it was used internally for benchmarking.

When I first made this package, I also tested it.

In the initial test, the situation was like this

KTLS TX > SW > KTLS RX > KTLS Both
When only TX is enabled, the throughput is doubled compared to SW.

In general, there are too many RX problems (performance regression, splice stuck after receiving BADMSG), See this comment

Therefore, I do not recommend turning on RX at this time.

The best thing about Kernel TLS is that you can use splice and sendfile to start zerocopy

Please continue testing, Thank you

Changes (v3)

• Command line changes reverted
• KTLS RX disabled by default
• EarlyData disabled by default

OK. Thanks for the information 👍🏼 Much appreciated.

The main function of ktls is to speed up the TX direction (through splice and sendfile)

If you use http2, turning on ktls may be a negative optimization

So our recommendation is to use HTTP/1.1 with compression turned off

The recommended kernel is Linux 6.x+

6.14 added KeyUpdate method (But probably not many servers or clients will send it)

I just pushed a new commit to support ktls KeyUpdate, please update the dependencies yourself after the merge if you need to.
(I'm not sure if the previous version works, but in theory it's fine to call setup again to rekey)