All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/6] RFH: We lost "connect" events
Date: Mon, 19 Aug 2019 12:06:04 +0100	[thread overview]
Message-ID: <20190819110604.GH12960@redhat.com> (raw)
In-Reply-To: <CAFEAcA-00fv0q7gg_j0ZZT5cp0sNJVf_yXk174E0svx1e5hdSQ@mail.gmail.com>

On Mon, Aug 19, 2019 at 12:00:15PM +0100, Peter Maydell wrote:
> On Mon, 19 Aug 2019 at 11:50, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > I don't think we want to expose this in the QAPI schema for the socket
> > address, since the correct value is really something that QEMU should
> > figure out based on usage context.
> >
> > Thus, I think we'll have to make it an explicit parameter to the
> > qio_channel_socket_listen_{sync,async} APIs, and socket_listen()
> > and inet_listen_saddr(), etc. Then the migration code can pass in
> > a sensible value based on multifd usage.
> 
> How bad would it be if we just passed SOMAXCONN for the backlog
> value always?

I'm not 100% clear to be honest, but my feeling is that this will waste
resources for much of QEMU usage where we only ever accept a single
client connection on an incoming socket.

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 :|


  reply	other threads:[~2019-08-19 11:06 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é
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é [this message]
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=20190819110604.GH12960@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 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.