On 8/17/22 01:11, Adel Abouchaev wrote: > QUIC requires end to end encryption of the data. The application usually > prepares the data in clear text, encrypts and calls send() which implies > multiple copies of the data before the packets hit the networking stack. > Similar to kTLS, QUIC kernel offload of cryptography reduces the memory > pressure by reducing the number of copies. > > The scope of kernel support is limited to the symmetric cryptography, > leaving the handshake to the user space library. For QUIC in particular, > the application packets that require symmetric cryptography are the 1RTT > packets with short headers. Kernel will encrypt the application packets > on transmission and decrypt on receive. This series implements Tx only, > because in QUIC server applications Tx outweighs Rx by orders of > magnitude. > > Supporting the combination of QUIC and GSO requires the application to > correctly place the data and the kernel to correctly slice it. The > encryption process appends an arbitrary number of bytes (tag) to the end > of the message to authenticate it. The GSO value should include this > overhead, the offload would then subtract the tag size to parse the > input on Tx before chunking and encrypting it. > > With the kernel cryptography, the buffer copy operation is conjoined > with the encryption operation. The memory bandwidth is reduced by 5-8%. > When devices supporting QUIC encryption in hardware come to the market, > we will be able to free further 7% of CPU utilization which is used > today for crypto operations. > Hmmm... I can't cleanly applied this series on top of current net-next. Exactly on what commit this series is based on? Also, I see two whitespace warnings when applying. Please fixup and resend. When resending, don't forget to pass --base to git-format-patch(1). Thanks. -- An old man doll... just what I always wanted! - Clara
