QAT driver

Özkan KIRIK ozkan.kirik at gmail.com
Mon Nov 9 19:13:16 UTC 2020


Running OS is not updated yet. It's a FreeBSD 12.1 stable. So drivers were
not attached.

On Mon, Nov 9, 2020 at 10:08 PM Özkan KIRIK <ozkan.kirik at gmail.com> wrote:

> This is cutted output, full output is attached. It's using C620. I think
> it's supported.
> There are two QAT chips SoC. Is it possible to use both of them ?
>
> none100 at pci0:181:0:0:   class=0x0b4000 card=0x00008086 chip=0x37c88086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'C62x Chipset QuickAssist Technology'
>     class      = processor
> none101 at pci0:182:0:0:   class=0x0b4000 card=0x00008086 chip=0x37c88086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'C62x Chipset QuickAssist Technology'
>     class      = processor
>
>
>
> On Mon, Nov 9, 2020 at 9:53 PM Mark Johnston <markj at freebsd.org> wrote:
>
>> 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 at 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 at freebsd.org mailing list
>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> > > To unsubscribe, send any mail to "
>> freebsd-hackers-unsubscribe at freebsd.org"
>> > >
>>
>


More information about the freebsd-hackers mailing list