ccr: Use a software OCF session for requests which fallback to software.

[jhb]

Summary

Previously the driver duplicated code from cryptosoft.c to handle
certain edge case AES-CCM and AES-GCM requests. However, this approach
has a few downsides:

1. It only uses "plain" software and not accelerated software since it uses enc_xform directly.

2. It performs the operation synchronously even though the caller believes it is invoking an async driver. This was fine for the original use case of requests with only AAD and no payload that execute quickly, but is a bit more disingenuous for large requests which fall back due to exceeding the size of a firmware work request (e.g. due to large scatter/gather lists).

3. It has required several updates since ccr(4) was added to the tree.

Instead, allocate a software session for AES-CCM and AES-GCM sessions
and dispatch a cloned request asynchronusly to the software session.

Sponsored by: Chelsio Communications

[markj]

sys/dev/cxgbe/crypto/t4_crypto.c

193

I think some comment explaining the purpose of this session would be useful.

1789

It'd be worth fixing this, I suspect: if ASYNC_ORDERED is specified, then callbacks are invoked by crypto worker threads. So crypto_dispatch_async() schedules a thread to perform the operation, and that thread will schedule another thread to call ccr_soft_done(), but that second context switch doesn't accomplish anything if the original dispatcher doesn't request ASYNC_ORDERED.

[jhb]

sys/dev/cxgbe/crypto/t4_crypto.c

1789

It is true that you get a wasted context switch, but I was more worried about correctness. It's also true that I think that the requests needing software fallbacks are rare (e.g. AAD-only requests for GCM/CCM, or requests with AAD > 512 that the kernel never uses), so I'm not super worried about optimizing them.