From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Peter Lieven <pl@kamp.de>,
qemu-devel <qemu-devel@nongnu.org>,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events
Date: Wed, 8 Apr 2015 10:08:09 -0700 [thread overview]
Message-ID: <CAN05THTKRQWBNH-HciHuoRvVi+eyCE7A4uZB6bOF2pqAgL0vEA@mail.gmail.com> (raw)
In-Reply-To: <CAJSP0QWVGNKbebVS7HV7EBcjzAeiinWFxT9=DmXyc5YUeOufMw@mail.gmail.com>
On Wed, Apr 8, 2015 at 1:38 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Tue, Apr 7, 2015 at 9:08 PM, Peter Lieven <pl@kamp.de> wrote:
>
> Please CC qemu-devel@nongnu.org in the future. All patches must be on
> the qemu-devel mailing list so they can be merged (for transparency).
> I have added qemu-devel to CC.
>
>> + /* newer versions of libiscsi may return zero events. In this
>> + * case start a timer to ensure we are able to return to service
>> + * once this situation changes. */
>> + if (!ev) {
>> + timer_mod(iscsilun->event_timer,
>> + qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + EVENT_INTERVAL);
>> }
>
> This suggests that libiscsi is waiting on its own internal timer. It
> would be cleaner for libiscsi to provide a timeout value so the
> application doesn't need to poll the library. Is there still scope to
> modify libiscsi to do this?
I think that returning a timeout value would be a bigger change in the
API that Peter wanted to avoid.
We discussed that as an option by my take from it was that this would
require that qemu and libiscsi
again would have to be updated in lockstep,
In this particular case with creating a delay between failed reconnect
attempts, i.e. the target is restarting and
returning a RST to the SYN request until it has fully restarted, the
correct amount of time to wait until re-trying is at best a guess
anyway.
I don't have any particular feelings on whether the decision on how
long to wait is done inside libiscsi and communicated to qemu,
or if it is done in qemu itself.
The nice part with the current patch of Peter is that qemu and
libiscsi can be upgraded/downgraded independently.
next prev parent reply other threads:[~2015-04-08 17:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1428437295-29577-1-git-send-email-pl@kamp.de>
2015-04-08 8:38 ` [Qemu-devel] [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events Stefan Hajnoczi
2015-04-08 17:08 ` ronnie sahlberg [this message]
2015-04-08 19:22 ` Stefan Hajnoczi
2015-04-08 19:36 ` Peter Lieven
2015-04-09 9:24 ` Stefan Hajnoczi
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=CAN05THTKRQWBNH-HciHuoRvVi+eyCE7A4uZB6bOF2pqAgL0vEA@mail.gmail.com \
--to=ronniesahlberg@gmail.com \
--cc=pbonzini@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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).