Date: Tue, 28 Jan 2020 23:01:31 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: how to use the ktls Message-ID: <YQBPR0101MB14277EAB1553C3049B60E763DD0A0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <d29b4343-b8e0-88e7-9076-d2a94eb45386@FreeBSD.org> References: <YQBPR0101MB142760894682CA3663CB53BDDD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> <YQBPR0101MB1427F6950084C3CA30713A75DD080@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>, <d29b4343-b8e0-88e7-9076-d2a94eb45386@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:=0A= [stuff snipped]=0A= >I don't know yet. :-/ With the TOE-based TLS I had been testing with, thi= s doesn't=0A= >happen because the NIC blocks the data until it gets the key and then it's= always=0A= >available via KTLS. With software-based KTLS for RX (which I'm going to s= tart=0A= >working on soon), this won't be the case and you will potentially have som= e data=0A= >already ready by OpenSSL that needs to be drained from OpenSSL before you = can=0A= >depend on KTLS. It's probably only the first few messsages, but I will ne= ed to figure=0A= >out a way that you can tell how much pending data in userland you need to = read via=0A= >SSL_read() and then pass back into the kernel before relying on KTLS (it w= ould just=0A= >be a single chunk of data after SSL_connect you would have to do this for)= .=0A= I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and the= n it throws=0A= away non-application data records. (Not sure, ssl3_read_bytes() gets pretty= convoluted at=0A= a glance.;-)=0A= =0A= I've found another issue that should keep me amused for a while (this is be= coming an=0A= interesting little project;-).=0A= The KERN_TLS needs unmapped pages on the mbuf chain, but that isn't what NF= S=0A= generates.=0A= I think I'll have to implement some sort of copy function that creates mbuf= s with unmapped=0A= pages and then maps them into kernel space for long enough that the data ca= n be copied,=0A= called just before sosend(). Most NFS RPC messages will easily fit in one p= age.=0A= =0A= Someday, the biggies like server read reply may be able to do what sendfile= does and=0A= put the read data in unmapped page mbufs, avoiding the long list of mbuf cl= usters=0A= that VOP_READ() currently copies the data into.=0A= --> But that's longer term than getting this to work.;-)=0A= =0A= Thanks for all your help John, rick=0A= =0A= > I'm currently testing with a kernel that doesn't have options KERN_TLS an= d=0A= > (so long as I get rid of the 478 bytes), it then just does unencrypted RP= Cs.=0A= >=0A= > So, I guess the big question is.... can I get access to your WIP code for= KTLS=0A= > receive? (I have no idea if I can make progress on it, but I can't do a l= ot more=0A= > before I have that.)=0A= =0A= The WIP only works right now if you have a Chelsio T6 NIC as it uses the T6= 's TCP=0A= offload engine to do TLS. If you don't have that gear, ping me off-list. = It=0A= would also let you not worry about the SSL_read case for now for initial te= sting.=0A= =0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB14277EAB1553C3049B60E763DD0A0>