Date: Mon, 2 Mar 2020 22:40:13 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, Rick Macklem <rmacklem@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-projects@freebsd.org" <svn-src-projects@freebsd.org> Subject: Re: svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient Message-ID: <YTBPR01MB33748EC38254A39C22F7CFAADDE70@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <de3e5a30-c36a-916d-2de1-1ee4154d2782@FreeBSD.org> References: <202002172110.01HLAXZY003012@repo.freebsd.org> <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org> <YTBPR01MB33742D4B8CB9DB7107564927DDE90@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>, <de3e5a30-c36a-916d-2de1-1ee4154d2782@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:=0A= >On 2/28/20 8:57 PM, Rick Macklem wrote:=0A= >> John Baldwin wrote:=0A= >>> On 2/17/20 1:10 PM, Rick Macklem wrote:=0A= >>>> Author: rmacklem=0A= >>>> Date: Mon Feb 17 21:10:32 2020=0A= >>>> New Revision: 358053=0A= >>>> URL: https://svnweb.freebsd.org/changeset/base/358053=0A= >>>>=0A= >>>> Log:=0A= >>>> Update nfs_clrpcops.c to handle ext_pgs mbufs, including the additio= nal=0A= >>>> argument to nfscl_reqstart() to tell it if it should build ext_pgs m= bufs.=0A= >>>>=0A= >>>> This completes most of the conversion to support of ext_pgs mbufs, b= ut=0A= >>>> there are still a couple of areas to fix.=0A= >>>> 1 - The code that the MDS uses to do a proxy to a DS for a pNFS serv= er.=0A= >>>> 2 - The krpc code on the receive side. (The NFS code now handles the= =0A= >>>> ext_pgs mbufs, but they are being created by copying the regular= mbuf=0A= >>>> list when the NFS code gets it from the krpc.) The krpc still ne= eds=0A= >>>> to be fixed so it can handle a list of ext_pgs mbufs handed to i= t=0A= >>>> by soreceive().=0A= >>>=0A= >>> Note that the current KTLS RX support I've worked on is a bit different= in that=0A= >>> it doesn't use ext_pgs mbufs. Instead the socket buffer contains a lis= t of=0A= >>> records (OpenSSL uses recvmsg()) where there is a control mbuf with the= TLS=0A= >>> header followed by a chain of normal mbufs with the data. As such, you= will=0A= >>> only have to construct ext_pgs mbufs for the send side. Receive will s= till=0A= >>> be getting regular mbufs. For receive you probably want to check the T= LS=0A= >>> record type and do something (not sure?) with any non-application-data = records,=0A= >>> but otherwise just treat the payload of application-data records the sa= me as=0A= >>> you do for the non-TLS case.=0A= >> Ok. I've already done the receive side code changes to handle ext_pgs mb= ufs=0A= >> in the krpc/nfs code, so if it becomes easier/more efficient to put the = receive=0A= >> data in ext_pgs mbufs, that can be handled. (Someday there may be net=0A= >> interfaces that perform better using ext_pgs mbufs?)=0A= >>=0A= >> Any non-data records that need to be handled by OpenSSL in userspace can= =0A= >> be passed up/handled by the daemons, similar to SSL_connect()/SSL_accept= ().=0A= >>=0A= >> Thanks for the info John, rick=0A= >=0A= >Ok. After sending this, I do think it is likely that for NICs able to do = TLS=0A= >RX without TOE, TLS records may indeed arrive as ext_pgs mbufs, but by the= time=0A= >you would get them out of the socket buffer the TLS headers and trailers w= ould=0A= >be stripped and they would just be unmapped mbufs holding the TLS record p= ayload.=0A= >The TLS header would still be in a control message in the socket buffer.= =0A= Should be fine for the code I've written, so long as the pages are anonymou= s.=0A= (If not, the code will need to know a way to allocate a page.)=0A= For example, I have a function similar to m_split(), but it doesn't try to = duplicate=0A= a hdr mbuf and handles anonymous ext_pgs mbufs. When the split is in the=0A= middle of a page, it allocates a new mbuf with a new page for the first par= tial=0A= page and moves the rest of the pages to it.=0A= (Actually, all of the functions like m_split() could be generalized to hand= le=0A= ext_pgs mbufs if there was an "allocate page" function for them and if mbu= fs=0A= with an m_len =3D=3D 0 were allowed in the chain.)=0A= =0A= >I started testing my KTLS RX software branch Friday btw (panicked right aw= ay=0A= >of course, but it's hopefully not too far away). For now I'm only focused= on=0A= >TLS 1.0-1.2, but will get to 1.3 eventually. I suspect for 1.3 that early= data=0A= >will still be handled in userland and just as for KTLS TX, KTLS RX will on= ly=0A= >be used with the second set of keys.=0A= John, I didn't think you ever wrote code that crashed;-)=0A= Sounds good. Let me know when you have patch(es) to test.=0A= =0A= Have fun with it, rick=0A= =0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB33748EC38254A39C22F7CFAADDE70>