I think the answer here is "no", but I'm going to ask anyway in case I'm forgetting something.
Consider an inbound (or forwarded) IPsec packet. Today, I call the Encryption Framework in a mode that allows the framework to queue my request asynchronously. In some cases, we queue all the time, in other cases we trust the framework to do the right thing depending on what's actually doing the crypto. We're finding that we have a hardware provider that allows synchronous operations, but EF will ALWAYS do asynch from IPsec because IPsec *allows* the *possibility* of async. We've seen HW accelerators not perform as well as it could because IPsec always calls the EF with "you CAN use async" as a parameter. If we call EF with pure synchronous calls, however, we may block a long time, and that would be theoretically be BAD for IP input processing. No locks are held, IIRC, during the part of ip_input() that calls IPsec, and no locks are held in IPsec during the crypto-dispatch routines. So here's the $1M questions: Can I call a blocking function from ip_input() if no locks are being held? (And at worse, I'm only reference-holding objects?) Crypto and HW folks are included - please include them in followups. Thanks, Dan _______________________________________________ networking-discuss mailing list [email protected]
