Parallel crypto/IPsec v7
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 0 repliesNew
Changes from v6 from the cover letter
- Rework padata to use workqueues instead of softirqs for parallelization/serialization
- Add a cyclic sequence number pattern, makes the reset of the padata serialization logic on sequence number overrun superfluous.
- Adapt pcrypt to the changed padata interface.
- Rebased to linux-2.6.33-rc1
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | padata: generic parallelization/serialization interfaceinclude/ init/ kernel/ +1 more | +783 | 0 replies | |
| 2/2 | crypto: pcrypt - Add pcrypt crypto parallelization wrappercrypto/ crypto/ crypto/ +1 more | +507 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] Parallel crypto/IPsec v7
This patchset adds the 'pcrypt' parallel crypto template. With this template it is possible to process the crypto requests of a transform in parallel without getting request reorder. This is in particular interesting for IPsec.
The parallel crypto template is based on the 'padata' generic parallelization/serialization method. With this method data objects can be processed in parallel, starting at some given point.
The parallelized data objects return after serialization in the order as they were before the parallelization. In the case of IPsec, this makes it possible to run the expensive parts in parallel without getting packet reordering.
IPsec forwarding tests with two quad core machines (Intel Core 2 Quad Q6600) and an EXFO FTB-400 packet blazer showed the following results:
On all tests I used smp_affinity to pin the interrupts of the network cards to different cpus.
linux-2.6.33-rc1 (64 bit)
Packetsize: 1420 byte
Test time: 60 sec
Encryption: aes192-sha1
bidirectional throughput without packet loss: 2 x 325 Mbit/s unidirectional throughput without packet loss: 325 Mbit/s
linux-2.6.33-rc1 (64 bit)
Packetsize: 128 byte
Test time: 60 sec
Encryption: aes192-sha1
bidirectional throughput without packet loss: 2 x 100 Mbit/s unidirectional throughput without packet loss: 125 Mbit/s
linux-2.6.33-rc1 with padata/pcrypt (64 bit)
Packetsize: 1420 byte
Test time: 60 sec
Encryption: aes192-sha1
bidirectional throughput without packet loss: 2 x 650 Mbit/s unidirectional throughput without packet loss: 850 Mbit/s
linux-2.6.33-rc1 with padata/pcrypt (64 bit)
Packetsize: 128 byte
Test time: 60 sec
Encryption: aes192-sha1
bidirectional throughput without packet loss: 2 x 100 Mbit/s unidirectional throughput without packet loss: 125 Mbit/s
So the performance win on big packets is quite good. But on small packets the troughput results with and without the workqueue based parallelization are amost the same on my testing environment.
Changes from v6:
- Rework padata to use workqueues instead of softirqs for parallelization/serialization
- Add a cyclic sequence number pattern, makes the reset of the padata serialization logic on sequence number overrun superfluous.
- Adapt pcrypt to the changed padata interface.
- Rebased to linux-2.6.33-rc1
Steffen