|
1 H4 crypto acceleration |
|
2 ====================== |
|
3 |
|
4 This directory tree contains a "proof of concept" H4 hardware |
|
5 acceleration device driver (crypto_h4) and the code required to plug |
|
6 it into the preq57 framework (crypto_h4_plugin). |
|
7 |
|
8 Support |
|
9 ------- |
|
10 |
|
11 NOT SUPPORTED! |
|
12 |
|
13 It is important to note that this plugin/driver is prototype test |
|
14 code, and is therefore NOT supported in any way. |
|
15 |
|
16 In particular it is NOT a reference driver. |
|
17 |
|
18 |
|
19 Limitations |
|
20 ----------- |
|
21 |
|
22 Currently the driver has several major limitations:- |
|
23 |
|
24 1) It is currently slower than the original software implementation... |
|
25 |
|
26 This is believed to be due to the following issues: |
|
27 |
|
28 a) Even using 100% of the H4 CPU power in a tight loop to write/read |
|
29 data to the crypto hardware only runs the driver test case about 30% |
|
30 faster than the old software crypto. |
|
31 |
|
32 b) The driver currently fakes DMA transfers for every block (ie. 16 |
|
33 bytes). |
|
34 |
|
35 Using real DMA, AND setting up longer DMAs may well cause a |
|
36 reduction in CPU loading and increase the throughput of the device |
|
37 driver. |
|
38 |
|
39 2) Whilst the driver does handle multiple simultaneous user requests, |
|
40 including scheduling between them to prevent starvation issues, some |
|
41 areas of the device driver are inefficient:- |
|
42 |
|
43 a) Both CryptoH4JobRandom and CryptoH4JobAes maintain buffers |
|
44 per-channel, even if that channel has never been used or is stalled. |
|
45 |
|
46 Most buffering should be moved to be common to all RNG/AES jobs, |
|
47 with the job objects only saving data needed to later resume a job. |
|
48 |
|
49 b) Scheduling for AES jobs is limited to when a job has stalled |
|
50 (ie. either drained all input data or filled the output buffer) |
|
51 |
|
52 Theoretically this could allow starvation problems. It is not |
|
53 clear if this is a real issue or not. It may be better to change |
|
54 the scheduling to only allow rescheduling between device driver |
|
55 requests, rather than within them. |
|
56 |
|
57 End of notes |