-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Richardson wrote: | Martin> How about a in-between application that want to use hardware, but in an | Martin> atomic fashion? This is how I started doing things before using a callback. | Martin> In some occasions, it might be good to be able to wait for the hardware | Martin> to finish encrypting by busy-looping. It is still more efficient to do | Martin> that then to wait for 3DES to finish in S/W. | | That would require some new interface into the device driver. | One could busy wait on some flag in the struct transform_command perhaps. | I'd like to understand the reason for this. If, like FreeS/WAN now, you want to replace crypto operations to use hardware but FreeS/WAN cannot wait while the hardware encrypts the packet, what do you do? What I did first is I replaced des_ede3_cbc_encrypt() with the one that does hardware, and wait for it to complete. YOu win, because time(HW) < time(SW). This is a drop-in replacement for existing applications that uses functions like des_ede3_cbc_encrypt(). Those application will benefits immedialtly from hardware acceleration. | | Martin> I therefore suggest to leave the hardware specification to the library. | | What do you mean by this? | | Martin> You want to say " I want this done ASAP, with those limitation (SYNC or | Martin> ASYN)". That way, the library chooses the best available hardware (or | Martin> software) to execute the request, according to specified | Martin> limitations. | | Sure, but users have to have a way to override things. Ok. "aes-cbc/hardware" would do that. | | Martin> Something is missing: the start of the operation, and size of the | Martin> operation. Is that included in tc_cmdqueue? | | Martin> Example: on packet pointer at tc_in, do HMAC from in+4 for size1, and | Martin> then do 3DES from in+16 for size2. | | My feeling is that one opens the "esp/3DES/HMAC-MD5" cipher if one wants it | done in one operation and ESP knows this stuff. Isn't that complicating the "Naming of ciphers"? In the FreeS/WAN hardware acceleration patch (http://sources.colubris.com) I use a structure for the request, and a list of transform (algorithm, offset, len) to do on the request. I though that is what you meant with the tc_cmdqueue member. | | Martin> We also need some kind of open_session()/close_session(). H/W can | Martin> remember keys (no need to transfer them with every command) but we need | Martin> to manage that either explicitly, on implicitly (use a LRU algo). On the | Martin> Hifn 7811 and 7901, there is a limited number of H/W session available, | Martin> due to memory constrains. | | That's handled by the driver by reference to the per-SA | struct cipher_context *tc_context; | | If you want to handle keys explicitely, I presume that this means locking | certain keys into the hardware, while cycling others? (For instance, VPN keys | stay in the hardware, while RW or OE get LRU). I would think that perhaps | this stuff goes into to initialization code for creating the cipher_context | ("open_session" as you call it). Possibly, but in any case, software need to oversee the hardware key management. The FreeS/WAN acceleration patch does not use H/W keys, as our application does not have extra memory to store keys. - -- ============== Martin Gadbois S/W Developper Colubris Networks Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAj07/bAACgkQ9Y3/iTTCEDlJdgCffGlxR7thVUjnfwnsrQy3q6Ox bd8An2FslAfq36FVA+GqdLKbDzdu/Llg =4MC5 -----END PGP SIGNATURE----- - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
