Avoid kernel_sendmsg() about af_ktls HOT 6 CLOSED

Here's the perf I'm getting: 80% is still in the helper_encrypt code, but a bit is still in sendmsg/recvmsg copying.

perf record -g ./client --sendfile file.txt --verbose --sendfile-size 10000000000 --server-host localhost --server-port 5555

from af_ktls.

I am getting:

• 47.45% from total spent in rfc5288_encrypt
  • 30% from total spent on actual encryption
  • 11.73% from total spent on copy - scatterwalk_map_and_copy
  • 1.24% from total spent in kmalloc
• 17.32% from total spent in kernel_sendmsg()
  • 7.72% form total in tcp_push_one (7% in actual transmit)
  • 4.23 from total in memcpy_erms

So to sum it up, ideally we could get cca 13% better results when rfc5288 would be optimized and additional cca 4% when kernel_sendpage() would be used instead of kernel_sendmsg(). These numbers are ideal though, there will be different paths which could (probably) introduce different issues.

Transferred 1GB file, reported by perf report --sort=symbol

from af_ktls.

According to benchmarks available at [1] with optimizations mentioned above (with 17% saved in total), we would reach similar values that I got by using mmap(2) on a file and sending it via Gnu TLS.

BTW perf reports context switches not expensive at all (0.40%).

http://209.132.179.123:5000/i7-4600U-2.10GHz/sendfile-file_100MB.bin-16000--tls/index.html

from af_ktls.

I'm trying to repro your mmap + gnutls results, I'm seeing it only slightly faster than read+ssl write.

Link is old and broken now. You were comparing the following two commands?

./client --sendfile-mmap
vs.
./client --sendfile

?

I'm trying to pull together some benchmark numbers for netdev.

from af_ktls.

You were comparing the following two commands?
./client --sendfile-mmap
vs.
./client --sendfile
?

Yes, exactly.

from af_ktls.

Closing, kernel_sendmsg() is not used now.

from af_ktls.