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?
-- Garrett
Right?
_______________________________________________
networking-discuss mailing list
[email protected]
