On Tuesday 30 January 2018 10:41 PM, Dave Watson wrote:
On 01/30/18 06:51 AM, Atul Gupta wrote:
What I was referring is that passing "tls" ulp type in setsockopt
may be insufficient to make the decision when multi HW assist Inline
TLS solution exists.
Setting the ULP doesn't choose HW or SW implementation, I think that
should be done later when setting up crypto with
setsockopt(SOL_TLS, TLS_TX, struct crypto_info).
setsockpot [mentioned above] is quite late for driver to enable HW
implementation, we require something as early as tls_init
[setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"))], for driver
to set HW prot and offload connection beside Inline Tx/Rx.
Any reason we can't use ethtool to choose HW vs SW implementation, if
available on the device?
Thought about it, the interface index is not available to fetch netdev
and caps check to set HW prot eg. bind [prot.hash] --> tls_hash to
program HW.
Some HW may go beyond defining sendmsg/sendpage of the prot and
require additional info to setup the env? Also, we need to keep
vendor specific code out of tls_main.c i.e anything other than
base/sw_tx prot perhaps go to hw driver.
Sure, but I think we can add hooks to tls_main to do this without a
new ULP.
Current code calls update_sk_prot for TLS_BASE_TX and TLS_SW_TX, future
Inline TLS assist HWs will add TLS_HW_TX, TLS_OFLD, ... etc additional
hooks to update sk prots can make code confusing?
