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! 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. 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()??? 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-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
