> -----Original Message-----
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Atul Gupta
> Sent: Thursday, February 8, 2018 3:56 PM
> To: Dave Watson <davejwat...@fb.com>
> Cc: s...@queasysnail.net; herb...@gondor.apana.org.au; linux-
> cry...@vger.kernel.org; ganes...@chelsio.co; netdev@vger.kernel.org;
> da...@davemloft.net; Boris Pismenny <bor...@mellanox.com>; Ilya
> Lesokhin <il...@mellanox.com>
> Subject: RE: [RFC crypto v3 8/9] chtls: Register the ULP
>
> I thought about this and approach below can avoid new ulp type:
>
> 1. Register Inline TLS driver to net TLS
> 2. enable ethtool -K <interface> tls-hw-record-offload on
> 3. Issue " setsockopt(fd, SOL_TCP, TCP_ULP, "tls", sizeof("tls")) " after
> Bind,
> this will enable user fetch net_device corresponding to ipaadr bound to
> interface, if dev found is the one registered and record-offload enabled,
> program the sk->sk_prot as required.
What happens in case of TLS clients which do not explicitly call bind() and
rely on kernel to choose an ephemeral port for socket?
Does calling setsockopt after the connection is established fix the problem?
> 4. fallback to SW TLS for any other case, bind to inaddr_any falls in this
> category and need proper handling?
>
> tls-hw-record-offload is TLS record offload to HW, which does tx/rx and
> record creation Inline.
>
> enum {
> TLS_BASE_TX,
> TLS_SW_TX,
> TLS_RECORD_HW, /* TLS record processed Inline */
> TLS_NUM_CONFIG,
> };
>
> -----Original Message-----
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Wednesday, January 31, 2018 10:14 PM
> To: Atul Gupta <atul.gu...@chelsio.com>
> Cc: s...@queasysnail.net; herb...@gondor.apana.org.au; linux-
> cry...@vger.kernel.org; ganes...@chelsio.co; netdev@vger.kernel.org;
> da...@davemloft.net; Boris Pismenny <bor...@mellanox.com>; Ilya
> Lesokhin <il...@mellanox.com>
> Subject: Re: [RFC crypto v3 8/9] chtls: Register the ULP
>
> On 01/31/18 04:14 PM, Atul Gupta wrote:
> >
> >
> > 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.
>
> Perhaps this is the part I don't follow - why do you need to override hash and
> check for LISTEN? I briefly looked through the patch named "CPL handler
> definition", this looks like it is a full TCP offload?
>
> Yes, this is connection and record layer offload, and the reason I used
> different ulp type, need to see what additional info or check can help setup
> the required sk prot.
