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: >On 2/28/20 8:57 PM, Rick Macklem wrote: >> John Baldwin wrote: >>> On 2/17/20 1:10 PM, Rick Macklem wrote: >>>> Author: rmacklem >>>> Date: Mon Feb 17 21:10:32 2020 >>>> New Revision: 358053 >>>> URL: https://svnweb.freebsd.org/changeset/base/358053 >>>> >>>> Log: >>>> Update nfs_clrpcops.c to handle ext_pgs mbufs, including the additional >>>> argument to nfscl_reqstart() to tell it if it should build ext_pgs mbufs. >>>> >>>> This completes most of the conversion to support of ext_pgs mbufs, but >>>> there are still a couple of areas to fix. >>>> 1 - The code that the MDS uses to do a proxy to a DS for a pNFS server. >>>> 2 - The krpc code on the receive side. (The NFS code now handles the >>>> ext_pgs mbufs, but they are being created by copying the regular mbuf >>>> list when the NFS code gets it from the krpc.) The krpc still needs >>>> to be fixed so it can handle a list of ext_pgs mbufs handed to it >>>> by soreceive(). >>> >>> Note that the current KTLS RX support I've worked on is a bit different in that >>> it doesn't use ext_pgs mbufs. Instead the socket buffer contains a list of >>> records (OpenSSL uses recvmsg()) where there is a control mbuf with the TLS >>> header followed by a chain of normal mbufs with the data. As such, you will >>> only have to construct ext_pgs mbufs for the send side. Receive will still >>> be getting regular mbufs. For receive you probably want to check the TLS >>> record type and do something (not sure?) with any non-application-data records, >>> but otherwise just treat the payload of application-data records the same as >>> you do for the non-TLS case. >> Ok. I've already done the receive side code changes to handle ext_pgs mbufs >> in the krpc/nfs code, so if it becomes easier/more efficient to put the receive >> data in ext_pgs mbufs, that can be handled. (Someday there may be net >> interfaces that perform better using ext_pgs mbufs?) >> >> Any non-data records that need to be handled by OpenSSL in userspace can >> be passed up/handled by the daemons, similar to SSL_connect()/SSL_accept(). >> >> Thanks for the info John, rick > >Ok. After sending this, I do think it is likely that for NICs able to do TLS >RX without TOE, TLS records may indeed arrive as ext_pgs mbufs, but by the time >you would get them out of the socket buffer the TLS headers and trailers would >be stripped and they would just be unmapped mbufs holding the TLS record payload. >The TLS header would still be in a control message in the socket buffer. Should be fine for the code I've written, so long as the pages are anonymous. (If not, the code will need to know a way to allocate a page.) For example, I have a function similar to m_split(), but it doesn't try to duplicate a hdr mbuf and handles anonymous ext_pgs mbufs. When the split is in the middle of a page, it allocates a new mbuf with a new page for the first partial page and moves the rest of the pages to it. (Actually, all of the functions like m_split() could be generalized to handle ext_pgs mbufs if there was an "allocate page" function for them and if mbufs with an m_len == 0 were allowed in the chain.) >I started testing my KTLS RX software branch Friday btw (panicked right away >of course, but it's hopefully not too far away). For now I'm only focused on >TLS 1.0-1.2, but will get to 1.3 eventually. I suspect for 1.3 that early data >will still be handled in userland and just as for KTLS TX, KTLS RX will only >be used with the second set of keys. John, I didn't think you ever wrote code that crashed;-) Sounds good. Let me know when you have patch(es) to test. Have fun with it, rick -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB33748EC38254A39C22F7CFAADDE70>