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.
Right?
Yes I assume that's the case - but I would argue that we are doing that
now when
software is chosen since it ends up being done synchronously.
-gary
_______________________________________________
networking-discuss mailing list
[email protected]
