Re: [RFC HIFN 00/02]: RNG support
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC HIFN 00/02]: RNG support
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC HIFN 00/02]: RNG support
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~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC HIFN 00/02]: RNG support
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?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC HIFN 00/02]: RNG support
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?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC HIFN 00/02]: RNG support
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 ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
