]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
KTLS: Coalesce adjacent TLS trailers & headers to improve PCIe bus efficiency
authorgallatin <gallatin@FreeBSD.org>
Mon, 30 Mar 2020 23:29:53 +0000 (23:29 +0000)
committergallatin <gallatin@FreeBSD.org>
Mon, 30 Mar 2020 23:29:53 +0000 (23:29 +0000)
commit9a5d50a84ca3e40db69afc51416a481f5efc1134
treec7b092d6307518fe7f9682f090fb404e83553896
parenta4796af6c5652aae589192cf5b53fac8ef8a14e7
KTLS: Coalesce adjacent TLS trailers & headers to improve PCIe bus efficiency

KTLS uses the embedded header and trailer fields of unmapped
mbufs. This can lead to "silly" buffer lengths, where we have an
mbuf chain that will create a scatter/gather lists with a
regular pattern of 13 bytes followed by 16 bytes between each
adjacent TLS record.

For software ktls we typically wind up with a pattern where we
have several TLS records encrypted, and made ready at once. When
these records are made ready, we can coalesce these silly buffers
in sbready_compress by copying 13b TLS header of the next record
into the 16b TLS trailer of the current record. After doing so,
we now have a small 29 byte chunk between each TLS record.

This marginally increases PCIe bus efficiency. We've seen an
almost 1Gb/s increase in peak throughput on Broadwell based Xeons
running a 100% software TLS workload with Mellanox ConnectX-4
NICs.

Note that this change is ifdef'ed for KTLS, as KTLS is currently
the only user of the hdr/trailer feature of unmapped mbufs, and
peeking into them is expensive, since the ext_pgs struct lives in
separately allocated memory, and may be cold in cache.

This optimization is not applicable to HW ("NIC") TLS, as that
depends on having the entire TLS record described by a single
unmapped mbuf, so we cannot shift parts of the record between
mbufs for HW TLS.

Reviewed by: jhb, hselasky, scottl
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24204
sys/kern/uipc_sockbuf.c