Hi,
Please see my comments inline below...
Thursday, May 19, 2005, 3:12:24 PM, you wrote:
> On Thu, 2005-05-19 at 14:47 +0100, Dan Searle wrote:
>> Hi,
>>
>> The problem with the existing IPsec stack and using OCF is that, for
>> some reason, a scatter gather list is used to split the packet data
>> into cypher block size chunks before sending them to the crypto API.
>> This is very bad for the IXP425 hardware crypto accelerator which
>> works much faster if you send it the entire plain text in one go
>> rather than dispatching the cypher block size chunks each in a
>> separate crypto context.
>>
>> For instance, I wrote a hardware crypto module which integrated with
>> OCF and the IPsec stack, but because the chunks of plain text were
>> dispatched to the hardware crypto engine in small (cypher block size)
>> chunks, the throughput was only about 1Mbit/sec!!!!
>>
>> I have recently thrown out the part of the IPsec stack which splits
>> the payloads using the scatter gather kernel functions, so that it
>> dispatches the entire plain text payload in one chunk. I.e. I dispatch
>> the entire packet to the IXP425 in one go. Using this method I'm now
>> getting about 20Mbit/sec throughput.
> Synchronous crypto stack splits original data to the small chunks,
> unfortunately.
> Although Herbert Xu moved away from it in the latest patches for crypto
> tree,
> but it is usefull for "synchronous" crypto devices like VIA/freescale
> processors.
> You definitely should not adopt your driver for IXP to the synchronous
> API,
> concider using OCF or acrypto directly from esp/ah output functions
> [actually I plan to release some code for it this weekend for acrypto
> and ESP].
I want to avoid adding the extra layer of complexity that OCF brings,
I want to call the IXP400 access libs crypto API directly from the
IPsec stack.
We already have the ESP output functions calling the IXP400 crypto API
directly, however, the problem is that... By the time the ESP output
function returns, doesn't the IPsec stack need the SKB to be finished
with? I.e. I thought that we had to "busy wait" in a loop within the
ESP output function until the crpyto API calls us back with the cypher
text, so that, by the time we exit the ESP output function, we have a
crypted SKB.
Perhapse I'm missing something. Can we exit from the ESP output
function before the SKB is actually crypted? How can we lock a
particular SKB until we are called back by the IXP400 crypto API
telling us the crypto is complete?
>> This is still far from optimal, because of the context I'm in and the
>> way I'm performing the crypto dispatch, it means I have to sit the
>> kernel in a busy loop until the IXP425 calls me back with the cypher
>> text.
>>
>> What I'm now trying to do is split the stack somehow, so that one
>> thread puts plain text skb's into the IXP425 dispatcher, and a new
>> thread sits on the other side and pulls the encrypted skb's out when
>> they are ready. Eliminating the need for a busy loop in a single
>> thread. Although, I'm not at all sure how to do this.
> You do not need to busywait until your crypto driver finishes the work.
> Concider link I sent before: there is dst entry tricky split
> which allows [thanks to it's stackability] asynchronous processing.
> I.e.
> skb_clone();
> setup crypto
> return 0; // here network stack thinks that skb is processed and queued
> to be sent to devices xmit fucntion.
> but since we cloned skb, we may return to it's processing later,
> for example from crypto finish callback.
> I.e.
> callback()
> {
> skb = some_priv_data;
> setup_new_dst_entry;
> dst_output(skb);
> }
Oops, looks like I should learn to read all of an email before
replying to one! However, I've just looked at the ESP output function
again, and I don't see it calling dst_output(). Perhaps I'm being
very dim and missed something here, but I can see exactly what you
mean, thanks for the pointer!
> It has disadvantage that there is no ability to inform original
> caller (xfrm) that skb was not processed due to some error.
This is not likely to happen unless we run into an OOM error, in which
case a few dropped frames are not your biggest problem anyway!
Thanks again, Dan....
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
