From: Amos Kong <akong@redhat.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: varadgautam@gmail.com, qemu-devel <qemu-devel@nongnu.org>,
Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend performance
Date: Tue, 17 Dec 2013 15:03:50 +0800 [thread overview]
Message-ID: <20131217070350.GA4270@amosk.info> (raw)
In-Reply-To: <20131217055214.GF6582@grmbl.mre>
On Tue, Dec 17, 2013 at 11:22:14AM +0530, Amit Shah wrote:
> On (Mon) 16 Dec 2013 [15:19:31], Anthony Liguori wrote:
> > On Mon, Dec 16, 2013 at 8:36 AM, Amit Shah <amit.shah@redhat.com> wrote:
> > > On (Mon) 09 Dec 2013 [22:10:12], Amos Kong wrote:
> > >> Bugzilla: https://bugs.launchpad.net/qemu/+bug/1253563
> > >>
> > >> We have a requests queue to cache the random data, but the second
> > >> will come in when the first request is returned, so we always
> > >> only have one items in the queue. It effects the performance.
> > >>
> > >> This patch changes the IOthread to fill a fixed buffer with
> > >> random data from egd socket, request_entropy() will return
> > >> data to virtio queue if buffer has available data.
> > >>
> > >> (test with a fast source, disguised egd socket)
> > >> # cat /dev/urandom | nc -l localhost 8003
> > >> # qemu .. -chardev socket,host=localhost,port=8003,id=chr0 \
> > >> -object rng-egd,chardev=chr0,id=rng0,buf_size=1024 \
> > >> -device virtio-rng-pci,rng=rng0
> > >
We have a wiki about about configing egd.
http://fedoraproject.org/wiki/QA:Testcase_Virtualization_VirtioRNG
> > > First thing I can think of is the egd protocol has a length field in
> > > the header, and if that isn't properly filled, the results are bound
> > > to be erratic.
The header setup in rng-egd.c is correct, we can check the debug
output of egd.pl
> > The test is bogus.
> >
> > egd is a protocol. You can't just pipe /dev/urandom into it.
In my test host, When I use the egd-socket, it is very slow.
So I use a quick souce /dev/urandom, we ignore the egd protocol
here, it might be wrong.
> Can you suggest a way to test this the right way?
It seems we should still use egd.pl to setup a daemon socket.
But how to make it very quick? We can't verify the performance
improvement if the source is too slow.
Can we use "--bottomless" option for egd.pl? it will not decrement
entropy count. When I use this option, the speed (without my patches)
is about 13 kB/s.
> Amit
--
Amos.
next prev parent reply other threads:[~2013-12-17 7:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 14:10 [Qemu-devel] [PATCH RFC 0/2] improve rng-egd perf Amos Kong
2013-12-09 14:10 ` [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend performance Amos Kong
2013-12-16 16:36 ` Amit Shah
2013-12-16 23:19 ` Anthony Liguori
2013-12-17 5:52 ` Amit Shah
2013-12-17 7:03 ` Amos Kong [this message]
2013-12-17 7:47 ` Markus Armbruster
2013-12-17 10:32 ` Amit Shah
2013-12-18 10:05 ` Giuseppe Scrivano
2013-12-24 9:58 ` Varad Gautam
2014-01-08 9:14 ` Amos Kong
2014-01-08 16:23 ` Amit Shah
2014-01-10 2:30 ` Amos Kong
2013-12-09 14:10 ` [Qemu-devel] [PATCH RFC 2/2] rng-egd: introduce a parameter to set buffer size Amos Kong
2013-12-10 16:58 ` Eric Blake
2013-12-12 2:55 ` Amos Kong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131217070350.GA4270@amosk.info \
--to=akong@redhat.com \
--cc=amit.shah@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
--cc=varadgautam@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).