We've tried to test and benchmark your submitted work[1].

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 

Catalin Vasile

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

Reply via email to