We've tried to test and benchmark your submitted work.
Cryptographic offloading is also used in IPsec in the Linux Kernel. In heavy
traffic scenarios, the NIC driver competes with the crypto device driver. Most
NICs use the NAPI context, which is one of the most prioritized context types.
In IPsec scenarios the performance is trashed because, although raw data gets
in to device, the data is encrypted/decrypted and the dequeue code in CAAM
driver has a hard time being scheduled to actually call the callback to notify
the networking stack it can continue working with that data.
Being this scenario, at heavy load, the Kernel warns on rcu stalls and the
forwarding path has a lot of latency.
Have you tried benchmarking the board you used for testing?
I have ran some on our other platforms. The after benchmark fails to run at the
top level of the before results. The rcu stall does not always stall in the
same place. The after ping latency is greater, and oscillates a lot.
It might be a good idea for the codebase to change to a threadirq, but from a
pragmatic perspective, the whole system has to suffer. That is one the reasons
most crypto accelerators try to run dequeue primitives in high priority
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html