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. 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. 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. - : 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
