All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Wei Wang <wei.w.wang@intel.com>,
	quintela@redhat.com, lei4.wang@intel.com, qemu-devel@nongnu.org
Subject: Re: [PATCH v1] migration: fail the cap check if it requires the use of deferred incoming
Date: Fri, 19 May 2023 11:31:44 -0400	[thread overview]
Message-ID: <ZGeWYAxayubPceOk@x1n> (raw)
In-Reply-To: <ZGcyr9d2qpYpV5As@redhat.com>

On Fri, May 19, 2023 at 09:26:23AM +0100, Daniel P. Berrangé wrote:
> On Thu, May 18, 2023 at 03:20:02PM -0400, Peter Xu wrote:
> > On Fri, May 19, 2023 at 12:00:26AM +0800, Wei Wang wrote:
> > > qemu_start_incoming_migration needs to check the number of multifd
> > > channels or postcopy ram channels to configure the backlog parameter (i.e.
> > > the maximum length to which the queue of pending connections for sockfd
> > > may grow) of listen(). So multifd and postcopy-preempt caps require the
> > > use of deferred incoming, that is, calling qemu_start_incoming_migration
> > > should be deferred via qmp or hmp commands after the cap of multifd and
> > > postcopy-preempt are configured.
> > > 
> > > Check if deferred incoming is used when enabling multifd or
> > > postcopy-preempt, and fail the check with error messages if not.
> > > 
> > > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > 
> > IIUC this will unfortunately break things like:
> > 
> >   -global migration.x-postcopy-preempt=on
> > 
> > where the cap is actually applied before incoming starts even with !defer
> > so it should still work.
> > 
> > Can we just make socket_start_incoming_migration_internal() listen on a
> > static but larger value?
> 
> Why do we need todo that ? I thought we just determined the problem was
> a configuration error, not a code error.

Yes, sorry I just read the other thread for more context.  So it seems my
concern wasn't really a concern anyway, now I'm fine with the current
approach.  Thanks,

-- 
Peter Xu



      reply	other threads:[~2023-05-19 15:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 16:00 [PATCH v1] migration: fail the cap check if it requires the use of deferred incoming Wei Wang
2023-05-18 19:20 ` Peter Xu
2023-05-19  2:34   ` Wang, Wei W
2023-05-19 15:30     ` Peter Xu
2023-05-19 15:33       ` Peter Xu
2023-05-20  1:42         ` Wang, Wei W
2023-05-22 23:36           ` Peter Xu
2023-05-23  1:44             ` Wang, Wei W
2023-05-23 13:40               ` Peter Xu
2023-05-23 14:30                 ` Wang, Wei W
2023-05-23 14:50                   ` Peter Xu
2023-05-24  1:47                     ` Wang, Wei W
2023-05-19  8:26   ` Daniel P. Berrangé
2023-05-19 15:31     ` Peter Xu [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=ZGeWYAxayubPceOk@x1n \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=lei4.wang@intel.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=wei.w.wang@intel.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.