Re: [RFC HIFN 00/02]: RNG support

[Patrick McHardy <kaber@trash.net>]

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 :)