Date: Sat, 29 Feb 2020 04:57:42 +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: <YTBPR01MB33742D4B8CB9DB7107564927DDE90@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org> References: <202002172110.01HLAXZY003012@repo.freebsd.org>, <fccc4f14-6b8a-7ab2-6614-52da1561946b@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 additiona= l=0A= >> argument to nfscl_reqstart() to tell it if it should build ext_pgs mbu= fs.=0A= >>=0A= >> This completes most of the conversion to support of ext_pgs mbufs, but= =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 server= .=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 m= buf=0A= >> list when the NFS code gets it from the krpc.) The krpc still need= s=0A= >> to be fixed so it can handle a list of ext_pgs mbufs handed to it= =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 list o= f=0A= >records (OpenSSL uses recvmsg()) where there is a control mbuf with the TL= S=0A= >header followed by a chain of normal mbufs with the data. As such, you wi= ll=0A= >only have to construct ext_pgs mbufs for the send side. Receive will stil= l=0A= >be getting regular mbufs. For receive you probably want to check the TLS= =0A= >record type and do something (not sure?) with any non-application-data rec= ords,=0A= >but otherwise just treat the payload of application-data records the same = as=0A= >you do for the non-TLS case.=0A= Ok. I've already done the receive side code changes to handle ext_pgs mbufs= =0A= in the krpc/nfs code, so if it becomes easier/more efficient to put the rec= eive=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= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB33742D4B8CB9DB7107564927DDE90>