All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ladi Prosek <lprosek@redhat.com>
To: Pankaj Gupta <pagupta@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] rng-random: implement request queue
Date: Thu, 4 Feb 2016 12:36:01 -0500 (EST)	[thread overview]
Message-ID: <370195749.32299292.1454607361313.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <2080961306.14671218.1454575993488.JavaMail.zimbra@redhat.com>

Hi Pankaj,

----- Original Message -----
> 
> Hi Ladi,
> 
> I think this is fine if we have multiple requests from Guests and
> depending on entropy pool available we can honour individual requests
> and return with the entropy.
> 
> Just one point I have is, Suppose we have multiple requests from Guests
> and we are returning if request length < 0 for any request. There might
> be pending requests which will get executed in next iteration?Can we honour
> them in same iteration?
> 
> static void entropy_available(void *opaque)
>  {
> ...
> ...
>  while (s->requests != NULL) {
> ...
> if (len < 0 && errno == EAGAIN) {
> +            return;
> +        }
> ...

All requests in the queue are waiting for data to be readable from the same
fd. If the fd has no data (read fails with EAGAIN), there's no point in
hammering on the fd in a loop. Returning seems to be the right thing to do.

Please let me know if I misunderstood your comment.
 
> Best regards,
> Pankaj
> > 
> > 
> > 
> > On 03/02/2016 13:36, Amit Shah wrote:
> > > ... and this can lead to breaking migration (the queue of requests on
> > > the host needs to be migrated, else the new host will have no idea of
> > > the queue).
> > 
> > It is already migrated as part of virtio_rng_save's call to virtio_save.
> >  On the loading side, virtio_rng_process condenses all requests into one
> > and chr_read fills in as many virtqueue buffers as possible from the
> > single request.
> > 
> > Cancel_requests seems useless.
> > 
> > Paolo
> > 
> 
> 

  reply	other threads:[~2016-02-04 17:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 12:19 [Qemu-devel] [PATCH] rng-random: implement request queue Ladi Prosek
2016-02-03 12:36 ` Amit Shah
2016-02-03 18:02   ` Ladi Prosek
2016-02-03 18:44   ` Paolo Bonzini
2016-02-04  8:53     ` Pankaj Gupta
2016-02-04 17:36       ` Ladi Prosek [this message]
2016-02-05  5:31         ` Pankaj Gupta
2016-02-04 17:24     ` Ladi Prosek
2016-02-04 18:07       ` Ladi Prosek
2016-02-05  8:32         ` Paolo Bonzini
2016-03-03  5:05         ` Amit Shah
2016-03-03  9:30           ` Ladi Prosek

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=370195749.32299292.1454607361313.JavaMail.zimbra@redhat.com \
    --to=lprosek@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.