From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>,
Eric Blake <eblake@redhat.com>, Jason Wang <jasowang@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] net: stream: add a new option to automatically reconnect
Date: Thu, 10 Nov 2022 11:37:44 +0000 [thread overview]
Message-ID: <Y2ziiGtM/EeS4lij@redhat.com> (raw)
In-Reply-To: <87v8nnhx5e.fsf@pond.sub.org>
On Thu, Nov 10, 2022 at 12:22:21PM +0100, Markus Armbruster wrote:
> Laurent Vivier <lvivier@redhat.com> writes:
>
> > In stream mode, if the server shuts down there is currently
> > no way to reconnect the client to a new server without removing
> > the NIC device and the netdev backend (or to reboot).
> >
> > This patch introduces a reconnect option that specifies a delay
> > to try to reconnect with the same parameters.
> >
> > Add a new test in qtest to test the reconnect option and the
> > connect/disconnect events.
> >
> > Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> > ---
>
> [...]
>
> > diff --git a/qapi/net.json b/qapi/net.json
> > index 522ac582edeb..5b72c936b3ac 100644
> > --- a/qapi/net.json
> > +++ b/qapi/net.json
> > @@ -585,6 +585,9 @@
> > # @addr: socket address to listen on (server=true)
> > # or connect to (server=false)
> > # @server: create server socket (default: false)
> > +# @reconnect: For a client socket, if a socket is disconnected,
> > +# then attempt a reconnect after the given number of seconds.
> > +# Setting this to zero disables this function. (default: 0)
>
> Double-checking: it attempts to reconnect *once*. Correct?
Repeatedly.
IIUC, this doesn't just try to reconnect a failed connection, it'll
reconnect the initial connection if the server doesn't listen when
QEMU first startup.
> Are we sure multiples of seconds will be fine?
FWIW, this text & behaviour (AFAICT) is identical to the same named
option against ChardevSocket, which is good for consistency.
Since the reconnect is continuous until connected, you don't
want too frequent reconnects otherwise it'll burn CPU time.
That said, if it wasn't for the pre-existing chardev option,
I would have suggested milliseconds be worth considering as
units. Arguably it should probaby have an increasing backoff.
We could achieve that without changing semantics in a way that
would matter to apps, by declaring that 'reconnect' is the
maximum reconnect time. So start a reconnect at 50ms, 100ms,
200ms, 500ms, 1s, .... $reconnect
IOW, I think its okey to set reconnect units to seconds, and
we have the option to retrofit the fast start + backwoff
later.
> "For a client socket": what happens for a server socket?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2022-11-10 11:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 7:34 [PATCH] net: stream: add a new option to automatically reconnect Laurent Vivier
2022-11-10 11:22 ` Markus Armbruster
2022-11-10 11:37 ` Daniel P. Berrangé [this message]
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=Y2ziiGtM/EeS4lij@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.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 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.