qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 18/21] migration: Make no compression operations into its


From: Dr. David Alan Gilbert
Subject: Re: [PATCH v3 18/21] migration: Make no compression operations into its own structure
Date: Fri, 24 Jan 2020 13:46:31 +0000
User-agent: Mutt/1.13.0 (2019-11-30)

* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> wrote:
> > * Juan Quintela (address@hidden) wrote:
> >> It will be used later.
> >> 
> >> Signed-off-by: Juan Quintela <address@hidden>
> >> 
> 
> >> +int migrate_multifd_method(void)
> >> +{
> >> +    MigrationState *s;
> >> +
> >> +    s = migrate_get_current();
> >> +
> >> +    return s->parameters.multifd_compress;
> >> +}
> >
> > Shouldn't that be a MultifdCompress enum returned?
> 
> You are right here.
> >>  
> >>  #define MULTIFD_FLAG_SYNC (1 << 0)
> >> +#define MULTIFD_FLAG_NOCOMP (1 << 1)
> >
> > I don't think this should be a set of individual flags; in later patches
> > you define a flag for zlib and another for zstd etc etc - but you can't
> > combine them - you could never have FLAG_NOCOMP|FLAG_ZSTD|FLAG_ZLIB - so
> > this should be a 3 or 4 bit field which contains a compression id (0
> > being none).  The ID can't exactly be the migrate_multifd_method() enum
> > value - because I don't think that's defined to be stable (?).
> 
> The idea is to catch up if we got an incorrect packet with an incorrect
> flag.
> 
> But yes, I agree that it could be the same expecting a value here.
> The problem is that I already have the flags field.
> 
> Would it be ok for you if I reserve 3 bits for this?  (right now 2
> should be enough).

Yeh that's fine - I was going to suggest 4 bits, but 3 is OK;
just define something like:

  MULTIFD_FLAG_COMP_MASK (7 << 1)

Dave

> Thanks, Juan.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK




reply via email to

[Prev in Thread] Current Thread [Next in Thread]