Remove rx async work about af_ktls HOT 6 CLOSED

The original idea was to decrypt asynchronously to user space and provide data with cost of a data copy (not to wait for Crypto API decryption).

from af_ktls.

I guess the optimal solution depends on the use case.
But I think we should consider removing the rx work on the following ground:

1. The CPU usage of the decryption is not attributed to the correct process.
2. If the user application is waiting in tls_recv message this is clearly a loss as it adds more data shuffling and context switches. In normal TCP proccessing, the kernel doesn't linearize incoming SKB asynchronously to speed up later tcp_recvmsg calls.

from af_ktls.

I guess the optimal solution depends on the use case.

Yes, exactly. In the worst case, if user space hits worker, there will be additional copy involved.

But I think we should consider removing the rx work on the following ground:

1. The CPU usage of the decryption is not attributed to the correct process.
2. If the user application is waiting in tls_recv message this is clearly a loss as it adds more data shuffling and context switches. In normal TCP proccessing, the kernel doesn't linearize incoming SKB asynchronously to speed up later tcp_recvmsg calls.

Sounds reasonable, I'm not a kernel dev though. The implementation would be simplified as well.

from af_ktls.

I think OP makes a great point. If we really only cared about throughput then the async worker is a good way to make use of idle cores, but this won't scale to large number of connections.

from af_ktls.

Patch for this #73. Dave will discuss this issue at netdev

from af_ktls.

Let's pull this in for now

from af_ktls.