[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxc: increase maximum migration stream record length



Andrew Cooper writes ("Re: [PATCH] libxc: increase maximum migration stream 
record length"):
> On 10/08/17 12:24, Juergen Gross wrote:
> > Today the maximum record lenth in a migration stream is 8MB. This
> > limits the size of a PV domain to a little bit less than 1TB in the
> > migration case, as the P2M frame list will exceed 8MB in this case.
> >
> > Raising the record size limit by a factor of 16 allows for domain
> > sizes of nearly 16TB to be migrated. This ought to be enough.
> >
> > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> 
> Hmm - Changing this isn't something I've considered when it comes to ABI
> compatibility.  I also see that there is no mention of the maximum
> record length in the stream spec, which is an oversight.
> 
> Worse still, there is no record length check in the python utilities,
> but both sides of the C code perform the check.
> 
> Let me ponder the implications.

I think simply changing this #define is the right approach.

What we mostly care about is that old senders can successfully send
data to new receivers, for which this is not an issue.

As regards new senders and old receivers:

This #define is not used to actually control the size of outgoing
records.  The only mentions are in safety checks, in both sending and
receiving side.

Therefore, in a situation where the old code would generate a
particular stream without error, the new code would generate exactly
the same stream.  (Likewise, obviously, the interpretation of existing
valid streams is not changed.)

The only difference in behaviour is that in some situations the old
sender will throw an error and abandon the migration attempt.  In
these same situations the new sender will generate a stream which will
be rejected by old receivers, but accepted by new receivers.

So increasing this #define is good:

 * All existing workin use cases work as before.

 * The new use case works with new code at both ends
   (this is the best that can be done because AIUI there is
    no way to represent this domain in a way that the old code
    would understand - although I have not verified this).

 * In one of the non-working cases the error handling is changed:
   the error is now detected at the receiver rather than at the
   sender.  This is, however, fine.

So:

Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.