[EMAIL PROTECTED] wrote:
Garrett D'Amore wrote:
[EMAIL PROTECTED] wrote:
Garrett D'Amore wrote:
James Carlson wrote:
[EMAIL PROTECTED] writes:
The n2cp driver will block the requestor on a cv, waiting for the
job to
finish. Its really not too different from going to the software
provider in this respect - we're just using the crypto
co-processor rather than
the cpu. The wait time is expected to be less than
the time to process the job in software. For small packets the
crypto
framework will route the job to software so we can selectively
choose to use the hw when its beneficial.
OK, so the real issue is that this potentially pins down and stalls
squeues and underlying driver interrupts that (in theory) could still
be doing useful work, if the message could be placed on a queue
rather
than blocked.
What about PIL related concerns? Are we guaranteed that the crypto
doesn't require an interrupt service routine to to run that won't
be blocked because we might already be in interrupt context?
In this case we're not using interrupts at all - the 1st job is just
spinning on a status bit - the other jobs get blocked on a cv and
are woke up by the spinning job when it is completed. However, we
can also run in async mode, in which case I share your PIL concerns.
I can imagine that running sync in this mode, where you don't
cv_wait, but spin on hardware, might be fine. especially if the
hardware is expected to run faster than software. (Sort of like
having a custom "crypto instruction" on the processor, I imagine.)
Early on we were doing just that (everyone spins) but that is really a
waste of processing power since the jobs are done in the order they
were placed in the queue, and you know you can't complete until
everyone in front of you does. So by putting jobs 2-n to sleep, those
strands go do something useful in the meantime.
Maybe putting them to sleep, per se, isn't the best approach. This is
where you need to go asynchronous in IPsec.
You definitely don't want to be doing a cv_wait on a thread that is
running in the context of ip_input(). That would be a bad idea.
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
Right?
_______________________________________________
networking-discuss mailing list
[email protected]
