Date: Mon, 9 Nov 2020 13:53:04 -0500 From: Mark Johnston <markj@freebsd.org> To: =?iso-8859-1?Q?=D6zkan?= KIRIK <ozkan.kirik@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: QAT driver Message-ID: <20201109185304.GB4990@raichu> In-Reply-To: <CAAcX-AE79kf=aMgqT=V7M8j1DXg0HdSwqW3u3p5E-pOkV_NkLw@mail.gmail.com> References: <20201026200059.GA66299@raichu> <723fbd7326df42ce30cd5e361db9c736@neelc.org> <20201027032720.GB31663@raichu> <YTBPR01MB39666C8CB2DA8292EA4E4033DD160@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <20201027125508.GD31663@raichu> <YTBPR01MB3966D1A13046294E5C10631DDD160@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <ca6dad2f-ddae-7b0b-06ac-50b52f624aa1@FreeBSD.org> <CAAcX-AE79kf=aMgqT=V7M8j1DXg0HdSwqW3u3p5E-pOkV_NkLw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 09, 2020 at 09:44:40PM +0300, Özkan KIRIK wrote: > great job! thank you! > > Does the work supports Xeon D-2100 series ? (Exact model: Xeon D-2146NT) > Regards I'm not sure - could you provide the PCI ID for the QAT device in question? "pciconf -lv" output would be sufficient. I don't see distinct Xeon D-2XXX support in any open-source QAT drivers, so it's probably covered by one of the other device types. > On Fri, Oct 30, 2020 at 6:45 PM John Baldwin <jhb@freebsd.org> wrote: > > > On 10/27/20 2:15 PM, Rick Macklem wrote: > > > Mark Johnston wrote: > > >> On Tue, Oct 27, 2020 at 04:32:40AM +0000, Rick Macklem wrote: > > > [stuff snipped] > > >>> Can it be made to work with the KERN_TLS in head? > > >>> (KERN_TLS works fine for me using the ktls_ocf and aesni modules.) > > >>> I think it is only head and requires the patched OpenSSL3 that jhb@ > > >>> currently has. > > >> > > >> I hadn't looked at ktls_ocf.c before but at a glance it looks like it > > >> can make use of any hardware or software opencrypto driver that supports > > >> the requested algorithms. The qat(4) port implements the algorithms > > >> referenced by ktls_ocf_try(). > > > Well, if you were inspired to try it out, the basic doc for NFS-over-TLS > > is here: > > > https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt > > > (Same file is in base/projects/nfs-over-tls on subversion.) > > > For someone who is used to building/running head kernels, it should be > > > pretty straightforward. > > > > > > You could become the first tester in the whole wide world;-) rick > > > ps: Although the NFS code uses it in the kernel, I think that an > > application > > > that uses OpenSSL's SSL_read()/SSL_write via a patched OpenSSL > > library, > > > has the encrypt/decrypt done in the kernel and the userspace library > > > code just does socket I/O with unencrypted data. > > > pss: Hopefully jhb@ will correct me if I got this wrong. > > > > > >> I know nothing about it, except that it seems to work well, doing > > >> the TLS application data records in the kernel for a TCP socket > > >> enabled by the patched OpenSSL library. > > >> I've cc'd jhb@, so hopefully he can let us know what it needs? > > > > qat(4) should work with KERN_TLS. I've used ccr(4) with the KERN_TLS > > bits many times. It is a good throughput test, though you will need > > a fast network connection to really push it (e.g. with ccr(4) I've > > done about 50 Gbps of TLS traffic using nginx with the KTLS patches > > to use sendfile, so that requires a 100G NIC and/or two 40G NICs.) > > > > -- > > John Baldwin > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201109185304.GB4990>