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].
> 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);
}
It has disadvantage that there is no ability to inform original
caller (xfrm) that skb was not processed due to some error.
> Regards, Dan...
>
> Thursday, May 19, 2005, 2:36:56 PM, you wrote:
>
>
> > Jivin Evgeniy Polyakov lays it down ...
> >> On Mon, 2005-05-16 at 11:38 +0100, Dan Searle wrote:
> >> > Hi People,
> >> >
> >> > Sorry if I'm reiterating, or posting anything to the wrong place,
> >> > but I'm new to the main line Kernel devel mailing lists, so please
> >> > bare with me!
> >> >
> >> > I'm currently re-writing the 2.6 IPsec stack so that it uses hardware
> >> > crypto on an IXP425 processor. This involves using the dreaded Intel
> >> > IXP400 Access Library, don't panic, I'm not about to ask how to
> >> > compile it!
> >>
> >> First of all, I would like to know do you want to use existing
> >> asynchronous
> >> crypto layers aka
> >> acrypto
> >> [http://tservice.net.ru/~s0mbre/?section=projects&item=acrypto]
> >> OCF [http://ocf-linux.sourceforge.net/]
> >> and if not, then why?
> >> They already provide all needed async callback mechanism and are
> >> designed specially for hardware crypto assistant.
>
> > Also, OCF already includes an IXP4xx driver. The current version on
> > sourceforge isn't quite up to the task for kernel level IPSEC processing,
> > but I think I have just fixed that part. I am just cleaning up the SKB
> > processing for both the hifn and safenet drivers and I should have
> > something worth a release.
>
> > Cheers,
> > Davidm
>
>
>
> --
>
> Dan Searle
> Adelix Ltd
> dan.searle@xxxxxxxxxx web: www.adelix.com
> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
> snail: The Old Post Office, Bristol Rd, Hambrook, Bristol BS16 1RY. UK.
>
> Any views expressed in this email communication are those
> of the individual sender, except where the sender specifically states
> them to be the views of a member of Adelix Ltd. Adelix Ltd. does not
> represent, warrant or guarantee that the integrity of this communication
> has been maintained nor that the communication is free of errors or
> interference.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
