From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/6] RFH: We lost "connect" events
Date: Mon, 19 Aug 2019 11:40:01 +0100 [thread overview]
Message-ID: <20190819104001.GF12960@redhat.com> (raw)
In-Reply-To: <87tvad30mu.fsf@trasno.org>
On Mon, Aug 19, 2019 at 12:33:45PM +0200, Juan Quintela wrote:
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Wed, Aug 14, 2019 at 04:02:18AM +0200, Juan Quintela wrote:
> >> When we have lots of channels, sometimes multifd migration fails
> >> with the following error:
> >> after some time, sending side decides to send another packet through
> >> that channel, and it is now when we get the above error.
> >>
> >> Any good ideas?
> >
> > In inet_listen_saddr() we call
> >
> > if (!listen(slisten, 1)) {
> >
> > note the second parameter sets the socket backlog, which is the max
> > number of pending socket connections we allow. My guess is that the
> > target QEMU is not accepting incoming connections quickly enough and
> > thus you hit the limit & the kernel starts dropping the incoming
> > connections.
> >
> > As a quick test, just hack this code to pass a value of 100 and see
> > if it makes your test reliable. If it does, then we'll need to figure
> > out a nice way to handle backlog instead of hardcoding it at 1.
>
> I will test.
>
> But notice that the qemu_connect() on source side says that things went
> right. It is the destination what is *not* calling the callback. Or
> at least that is what I think it is happening.
IIRC, the connect() can succeed on the source host, even if the target host
has not called accept(), because the kernel will complete the connection at
the protocol level regardless. IOW, don't assume that the destination QEMU
has seen the connection. If you turn on tracing, we have a trace point
"qio_channel_socket_accept_complete" that is emitted after we have done
an accept(). So you can see if you get 100 of those trace points emitted
on the target, when you make 100 connects on the source.
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 :|
next prev parent reply other threads:[~2019-08-19 10:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 2:02 [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels Juan Quintela
2019-08-14 2:02 ` [Qemu-devel] [PATCH 1/6] migration: Add traces for multifd terminate threads Juan Quintela
2019-08-14 11:17 ` Dr. David Alan Gilbert
2019-08-19 11:14 ` Philippe Mathieu-Daudé
2019-08-14 2:02 ` [Qemu-devel] [PATCH 2/6] migration: Make global sem_sync semaphore by channel Juan Quintela
2019-08-14 14:34 ` Dr. David Alan Gilbert
2019-08-14 2:02 ` [Qemu-devel] [PATCH 3/6] migration: Make sure that all multifd channels have been created Juan Quintela
2019-08-14 14:58 ` Dr. David Alan Gilbert
2019-08-19 8:29 ` Juan Quintela
2019-08-14 2:02 ` [Qemu-devel] [PATCH 4/6] migration: Make multifd threads wait until all " Juan Quintela
2019-08-14 2:02 ` [Qemu-devel] [PATCH 5/6] migration: add some multifd traces Juan Quintela
2019-08-14 16:23 ` Dr. David Alan Gilbert
2019-08-19 11:10 ` Philippe Mathieu-Daudé
2019-08-19 11:13 ` Philippe Mathieu-Daudé
2019-08-14 2:02 ` [Qemu-devel] [PATCH 6/6] RFH: We lost "connect" events Juan Quintela
2019-08-19 9:52 ` Daniel P. Berrangé
2019-08-19 10:33 ` Juan Quintela
2019-08-19 10:40 ` Daniel P. Berrangé [this message]
2019-08-19 10:46 ` Juan Quintela
2019-08-19 10:49 ` Daniel P. Berrangé
2019-08-19 10:50 ` Juan Quintela
2019-08-19 11:00 ` Peter Maydell
2019-08-19 11:06 ` Daniel P. Berrangé
2019-08-19 10:47 ` Juan Quintela
2019-08-14 11:43 ` [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels no-reply
2019-08-14 14:53 ` Dr. David Alan Gilbert
2019-08-14 23:24 ` no-reply
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=20190819104001.GF12960@redhat.com \
--to=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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 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).