Herbert Xu wrote:
On Sat, Nov 17, 2007 at 07:53:25PM +0000, Evgeniy Polyakov wrote:
The second patch adds hw_random support. The ugly part is finding out
when to allow reads from the RNG. It currently translates the public
key engine clock cycles to CPU cycles based on a 4GHz CPU and uses
get_cycles(). The problems with this are obvious, it only works on CPUs
that actually have some kind of cycle counter, has problems with
unsynchronized TSCs and the 4GHz assumption is not very nice either,
but I was reluctant to use ktime for this since it seems rather
expensive to call ktime_get once per 4 bytes of random. Suggestion
for improvement of this are also welcome :)
It will not work on arm, but I'm not sure this is relevant...
Another option is to directly access xtime without all wrappers in the
ktime_get().
Is it really that bad? You're most likely going to be spinning
for 10us in udelay() or worse busy-looping anyway so I'm not sure
if we need to worry about that overhead too much.
Thats a good point, the busy-waiting makes any overhead pretty
much irrelevant (10us is most like much more than ktime_get())
so I'm going to try using ktime_get. xtime doesn't seem suitable
since its only updated on timer interrupts.
On a related issue, I think the rng interface is not very suitable
for chips like HIFN that have a constant random bandwidth, it would
make a lot more sense to return the time to wait to the core, instead
of waiting 10us in all cases. 256 cycles at a speed of 266MHz comes
down to 0.96us, so we're waiting about 10 times as long as necessary.
Since its busy waiting anyway, I'd think that from a performance POV
constant polling or returning the exact amount of time would be more
reasonable.
Otherwise these patches look pretty nice to me. Thanks Patrick!
Fresh patches coming up tommorrow :)
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
