Hi Yugui,

Happy new year!

Thank you for the help! I have updated the patches according to your request:

- use listen/conn-addr on receive/send respectively
- use tcp-port: later we can support DTLS
- support --tls-mode none: in this mode, send/receive won't check for key file
or prompt for password.

Please let me know if you have any questions! I am very curious about the
performance of kernel TLS too.

Best regards,
Sheng

On Thu, Dec 31, 2020 at 10:53 PM Wang Yugui [off-list ref] wrote:

Hi, Sheng

quoted

Hi Yugui,

Thank you for the feedback!

1. Yes, we can do that. The reason why I use —tls-addr on both sides is to introduce least vocabulary for users.
2. I don’t have a 10Gpbs NIC to have a thorough benchmark on TLS vs raw sockets. The flame graph shows
decrypt_skb_update (related to TLS decoding) takes about 3.5% of CPU time for my 1Gbps setup. The transfer
saturates the bandwidth. Do you have any 10Gbps devices? Would you mind to help me benchmarking after
introducing —tls-mode none?

Yes. We can benchmark this for 10G Gbps or 40Gbs.

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2021/01/01

quoted

Thank you! Happy new year!

Regards,
Sheng

quoted

On Dec 31, 2020, at 04:16, Wang Yugui [off-list ref] wrote:

Hi, Sheng Mao

some feedback.

1, can we use 'listen-addr' for sever side, and 'conn-addr' for client
side?

2, can we support '--tls-mode none' for tcp without TLS,
and then change 'tls-port' to 'tcp-port'?

Is there some boost performance for tcp without TLS too?

quoted

+--tls-addr <url>::
+Address to listen on. It can be an IP address or a domain name.
+
+--tls-port <port>::
+The local port of the TLS connection.
+
+--tls-key <file>::
+Use the key from file; otherwise read key from stdin. Key file is first parsed
+as PEM format; if parsing fails, file content is treated as binary key.
+
+--tls-mode <mode>::
+Use tls_12_128_gcm, tls_13_128_gcm, tls_12_256_gcm.

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2020/12/31