@Dave Watson, Did you get chance to look at my response? 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. 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.
Sabrina echoed similar concern early last week, can we discuss or have thoughts how to address this? Thanks Atul -----Original Message----- From: Atul Gupta Sent: Sunday, January 28, 2018 11:26 AM To: 'Dave Watson' <davejwat...@fb.com> Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org; ganes...@chelsio.co; net...@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 -----Original Message----- From: Dave Watson [mailto:davejwat...@fb.com] Sent: Friday, January 26, 2018 2:39 AM To: Atul Gupta <atul.gu...@chelsio.com> Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org; ganes...@chelsio.co; net...@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 <1513769897-26945-1-git-send-email-atul.gu...@chelsio.com> On 12/20/17 05:08 PM, Atul Gupta wrote: > +static void __init chtls_init_ulp_ops(void) { > + chtls_base_prot = tcp_prot; > + chtls_base_prot.hash = chtls_hash; > + chtls_base_prot.unhash = chtls_unhash; > + chtls_base_prot.close = chtls_lsk_close; > + > + chtls_cpl_prot = chtls_base_prot; > + chtls_init_rsk_ops(&chtls_cpl_prot, &chtls_rsk_ops, > + &tcp_prot, PF_INET); > + chtls_cpl_prot.close = chtls_close; > + chtls_cpl_prot.disconnect = chtls_disconnect; > + chtls_cpl_prot.destroy = chtls_destroy_sock; > + chtls_cpl_prot.shutdown = chtls_shutdown; > + chtls_cpl_prot.sendmsg = chtls_sendmsg; > + chtls_cpl_prot.recvmsg = chtls_recvmsg; > + chtls_cpl_prot.sendpage = chtls_sendpage; > + chtls_cpl_prot.setsockopt = chtls_setsockopt; > + chtls_cpl_prot.getsockopt = chtls_getsockopt; > +} Much of this file should go in tls_main.c, reusing as much as possible. For example it doesn't look like the get/set sockopts have changed at all for chtls. Agree, should common code and anything other than TLS_BASE_TX/TLS_SW_TX prot should go in vendor specific file/driver. Since, prot require redefinition for hardware the code is kept in chtls_main.c > + > +static int __init chtls_register(void) { > + chtls_init_ulp_ops(); > + register_listen_notifier(&listen_notifier); > + cxgb4_register_uld(CXGB4_ULD_TLS, &chtls_uld_info); > + tcp_register_ulp(&tcp_chtls_ulp_ops); > + return 0; > +} > + > +static void __exit chtls_unregister(void) { > + unregister_listen_notifier(&listen_notifier); > + tcp_unregister_ulp(&tcp_chtls_ulp_ops); > + chtls_free_all_uld(); > + cxgb4_unregister_uld(CXGB4_ULD_TLS); > +} The idea with ULP is that there is one ULP hook per protocol, not per driver. One thought is that apps/lib calling setsockopt pass the required ulp type [tls or chtls or xtls], this enables any HW assist to define base_prot as required and keep common code [tls_main] independent of underlying HW. If we are to have single TLS ULP hook [good from user point] then need a way to determine which Inline tls hw is used? System with multiple Inline TLS capable hw and differing functionality would require checks in tls_main to exercise that specific functionality/callback?
