cxgbe: Use partial GCM mode for partial TLS records on T7HEADmain

T7's crypto co-processor adds a new partial GCM mode.  This permits an
AES-GCM operation to be split into multiple requests.  After each
request, the partial GHASH state is returned to the host and must be
included in the subsequent request to continue the GHASH computation.

Make use of this when sending a TLS record that spans multiple TCP
"request" (where a request can use TSO to span multiple segments).
This permits computing the final GHASH value across multiple requests
without having to re-send the entire TLS record for the final request.

To ensure that intermediate GHASH results are available when needed,
mbuf chains are queued in the TLS pcb and only dispatched one at a
time to the NIC TXQ.  Packets which do not request a GHASH result
queue the next mbuf from the connection as soon as they are written
into the TXQ.  Packets which do request a GHASH result queue the next
mbuf after the the GHASH result is returned by a message on a NIC RXQ.

Note that partial GCM mode is only used for the in-order data at the
"tip" of a connection and not for retransmits of earlier data.
Retransmits will not request a GHASH result so will enqueue the next
mbuf from the connection to the NIC TXQ after being written.

Partial GCM mode is also not TLS-aware and only supports "plain"
AES-GCM.  Thus, TLS AAD must be explicitly constructed and sent as
part of the work request in the TXQ at the start of each TLS record.
However, by avoiding the need to retransmit the entire TLS record's
contents for the last mbuf spanning a TLS record, the overall amount
of "wasted" DMA is reduced by a factor of about 30.

MFC after:	3 days
Sponsored by:	Chelsio Communications

0 files changed, 0 insertions, 0 deletions