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. Second: I'm currently creating async IPsec realisation for linux kernel, it is very simple [thanks to stackable dst entries]. You can find intial proof of concept code and discussion at http://marc.theaimsgroup.com/?l=linux-netdev&m=111477155306754&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=111512742002577&w=2 What you need there is just to poll out data processing [skb handling] from actuall crypting. > Thing is, the crypto API in the Intel libs is asynchronous, as in, > it's call-back based. I have written wrapper functions to make the > crypto dispatch call block until the buffer is ready, the problem is, > the IPsec stack is executed in SoftIRQ context. This means that while > I'm in a busy loop waiting for the buffer to become ready, i.e. > waiting for the IXP400 libs to call me back, I'm basically wasting > thousands of CPU cycles. This is wrong, concider above links, where right work deferring was introduced. > I've found a function in kernel/sched.c which looks like exactly what > I want..... > > cond_resched_softirq() > > Which gets called at other points in the NET stack, problem is, when I > call it in my busy loop, and pass lots of traffic through the IPsec > stack, the kernel crashes with "schedule() while atomic". > > I notice comments in the TCP stack code where cond_resched_softirq() is > called saying "it's safe to call this here". But no justification as to > why it's safe to call it. I'm in softirq context, what else needs to be > true for it to be safe to call cond_resched_softirq()??? You may not call it under lock - xfrm processing is always called under state lock, so you can catch it. > Any pointers much appreciated, regards, Dan... > > -- > > 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 -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Attachment:
signature.asc
Description: This is a digitally signed message part
