Jivin Dan Searle lays it down ... > 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. Have you looked at the ixp4xx driver in OCF ? It does full buffer operations. The version off sourceforge only does iovec and contiguous buffer operations. I should have an SKB processing version up tomorrow if I can get it tested properly tomorrow morning :-) > 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. It would be possible to take the skb or iov example in OCF and add direct scatterlist support to OCF using chained ixp mbufs. Currently you should be able to call into OCF using the contig buffer model just by pointing it at skb->data/len. At least for a start. > 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. What you need is a basic state machine that can continue processing when the callback occurs. I have done something similar to Openswan so it can use OCF. At the moment I have full async RX processing on the IXP425 using OCF and the ixp4xx driver or the cryptosoft driver. I have been cleaning up the driver support for this before I start the TX side, but so far it's working quite nicely, Cheers, Davidm > 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. > > - > : send the line "unsubscribe linux-crypto" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- David McCullough, davidm@xxxxxxxxxxxx Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - : 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
