* Re: [RFC HIFN 00/02]: RNG support
2007-11-18 4:04 ` [RFC HIFN 00/02]: RNG support Herbert Xu
@ 2007-11-18 4:04 ` Herbert Xu
2007-11-18 10:27 ` Michael Buesch
1 sibling, 0 replies; 3+ messages in thread
From: Herbert Xu @ 2007-11-18 4:04 UTC (permalink / raw)
To: Patrick McHardy
Cc: Evgeniy Polyakov, linux-crypto, Linux Kernel Mailing List, mb
On Sun, Nov 18, 2007 at 12:04:01PM +0800, Herbert Xu wrote:
> On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote:
> >
> > 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.
>
> I agree, a better interface would be to let the hardware do the
> blocking where necessary.
I meant the hardware driver of course.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [RFC HIFN 00/02]: RNG support
2007-11-18 4:04 ` [RFC HIFN 00/02]: RNG support Herbert Xu
2007-11-18 4:04 ` Herbert Xu
@ 2007-11-18 10:27 ` Michael Buesch
1 sibling, 0 replies; 3+ messages in thread
From: Michael Buesch @ 2007-11-18 10:27 UTC (permalink / raw)
To: Herbert Xu
Cc: Patrick McHardy, Evgeniy Polyakov, linux-crypto,
Linux Kernel Mailing List
On Sunday 18 November 2007 05:04:01 Herbert Xu wrote:
> On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote:
> >
> > 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.
>
> I agree, a better interface would be to let the hardware do the
> blocking where necessary.
>
> Michael, what do you think about this?
Patches are welcome. ;)
--
Greetings Michael.
^ permalink raw reply [flat|nested] 3+ messages in thread