From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50638)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1YaqKr-0006CO-Fv
	for qemu-devel@nongnu.org; Wed, 25 Mar 2015 14:47:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1YaqKo-0004NU-Jn
	for qemu-devel@nongnu.org; Wed, 25 Mar 2015 14:47:25 -0400
Received: from mx1.redhat.com ([209.132.183.28]:56668)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <dgilbert@redhat.com>) id 1YaqKo-0004NQ-C2
	for qemu-devel@nongnu.org; Wed, 25 Mar 2015 14:47:22 -0400
Date: Wed, 25 Mar 2015 18:47:16 +0000
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Message-ID: <20150325184715.GM2313@work-vm>
References: <1424883128-9841-1-git-send-email-dgilbert@redhat.com>
	<1424883128-9841-12-git-send-email-dgilbert@redhat.com>
	<20150310054725.GC11973@voom.redhat.com>
	<20150310143402.GB18865@work-vm>
	<20150311015442.GM11973@voom.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150311015442.GM11973@voom.redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 11/45] Return path: Send responses from
 destination to source
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com, pbonzini@redhat.com, yanghy@cn.fujitsu.com

* David Gibson (david@gibson.dropbear.id.au) wrote:
> On Tue, Mar 10, 2015 at 02:34:03PM +0000, Dr. David Alan Gilbert wrote:
> > * David Gibson (david@gibson.dropbear.id.au) wrote:
> > > On Wed, Feb 25, 2015 at 04:51:34PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > > 
> > > > Add migrate_send_rp_message to send a message from destination to source along the return path.
> > > >   (It uses a mutex to let it be called from multiple threads)
> > > > Add migrate_send_rp_shut to send a 'shut' message to indicate
> > > >   the destination is finished with the RP.
> > > > Add migrate_send_rp_ack to send a 'PONG' message in response to a PING
> > > >   Use it in the CMD_PING handler
> > > > 
> > > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > > ---
> > > >  include/migration/migration.h | 17 ++++++++++++++++
> > > >  migration/migration.c         | 45 +++++++++++++++++++++++++++++++++++++++++++
> > > >  savevm.c                      |  2 +-
> > > >  trace-events                  |  1 +
> > > >  4 files changed, 64 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/migration/migration.h b/include/migration/migration.h
> > > > index c514dd4..6775747 100644
> > > > --- a/include/migration/migration.h
> > > > +++ b/include/migration/migration.h
> > > > @@ -41,6 +41,13 @@ struct MigrationParams {
> > > >      bool shared;
> > > >  };
> > > >  
> > > > +/* Commands sent on the return path from destination to source*/
> > > > +enum mig_rpcomm_cmd {
> > > 
> > > "command" doesn't seem like quite the right description for these rp
> > > messages.
> > 
> > Would you prefer 'message' ?
> 
> Perhaps "message type" to distinguish from the the blob including both
> tag and data.

OK, done:

/* Messages sent on the return path from destination to source */
enum mig_rp_message_type {
    MIG_RP_MSG_INVALID = 0,  /* Must be 0 */

<snip>

> > > > +/*
> > > > + * Send a 'PONG' message on the return channel with the given value
> > > > + * (normally in response to a 'PING')
> > > > + */
> > > > +void migrate_send_rp_pong(MigrationIncomingState *mis,
> > > > +                          uint32_t value)
> > > > +{
> > > > +    uint32_t buf;
> > > > +
> > > > +    buf = cpu_to_be32(value);
> > > > +    migrate_send_rp_message(mis, MIG_RP_CMD_PONG, 4, (uint8_t *)&buf);
> > > 
> > > It occurs to me that you could define PONG as returning the whole
> > > buffer that PING sends, instead of just 4-bytes.  Might allow for some
> > > more testing of variable sized messages.
> > 
> > Yes; although it would complicate things a lot if I made it fully generic
> > because I'd have to worry about allocating a buffer etc and I'm not
> > making vast use of the 4 bytes I've already got.
> 
> Couldn't migrate_send_rp_pong just take a buf pointer and length, then
> you can point that directly at the buffer in the ping message you've
> received.

The buffer is a few levels down at that point, so it's non-trivial
to do that, where as it's currently very very simple to just pass
that fixed length value; and it's only a bit of debug.

Dave

> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK