[EMAIL PROTECTED] 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.
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.
It is safe for a software provider to handle the IPsec request
synchronously
because it guarantees non-blocking behavior (i.e. allocation with
KM_NOSLEEP,
no cv_wait etc.). I am not sure if a hardware provider can guarantee
non-blocking behavior.
In any case, existing hardware crypto providers like SCA6000 do
block because the crypto framework SPI says it is safe to block
for a hardware provider. These providers will not play nice
with a changed IPsec.
-Krishna
_______________________________________________
networking-discuss mailing list
[email protected]
