On 4/1/2018 6:27 PM, Boris Pismenny wrote: > Hi, > > On 4/1/2018 6:37 AM, David Miller wrote: >> From: Atul Gupta <atul.gu...@chelsio.com> >> Date: Sat, 31 Mar 2018 21:41:51 +0530 >> >>> Series for Chelsio Inline TLS driver (chtls) >> >> Series applied, thank you. >> > > Sorry for being late to the party, could you please help answer a few > questions to help me understand better. Going over these points and addressing some of them in follow-up patches: > > 1. What happens if someone attempts to set a TCP socket option for a socket > whose TCP stack resides in the TCP offload engine(TOE)? Do you emulate all > Linux socket options? What about IP socket options? HW offloaded options are handled while rest shall be redirected to host. > > If I follow the code correctly, then the original TCP/IP setsockopt is > called. But, it doesn't change any of the parameters of the TCP/IP offload > engine in hardware. > > 2. I can't find where is the TLS record sequence number pushed to hardware. > Is that on purpose? seq-nos is pushed to HW in cpl_tx_tls_sfo->scmd1 > > FYI, ignoring this parameter might cause a record sequence number reuse which > breaks the integrity of the AES-GCM TLS ciphersuite. > > 3. How does a TOE handle Tx only or Rx only? Driver does not differentiate/isolate the tx and rx path for Inline Processing > > 4. What happens when there is a routing change that redirects traffic to a > different netdev? Is there a software fallback? The case we think is handling the next hop change, is there any other case? > > 5. The TLS socket option is set in the middle of a TCP connection. What > happens to the existing TCP connection and the data that is currently queued > in the TCP write queue? I believe this behave same as SW. If by TLS options you mean re-keying then outstanding data on Tx is flushed before new key takes effect. For Rx user should be careful else it will result in MAC error.
Thanks Atul > > Thanks, > Boris. >
