Hi, > > > +Wire format > > > +=========== > > > + > > > +Unless specified differently, numbers are in the machine native byte > > > +order. > > > + > > > +A vhost-user-gpu request consists of 2 header fields and a payload. > > > + > > > ++---------+------+---------+ > > > +| request | size | payload | > > > ++---------+------+---------+ > > > + > > > +Header > > > +------ > > > + > > > +:request: ``u32``, type of the request > > > + > > > +:size: ``u32``, size of the payload > > > + > > > +A reply consists only of a payload, whose content depends on the request. > > > > I'd suggest to use the same format for replies, only with "request" > > meaning "status" in replies. Allows for OK/ERROR status in replies, > > and having a size field in replies too should make things more robust. > > Also allows for an empty reply (status=ok,size=0). > > > That brings more questions and ambiguity imho.
What questions for example? > Can we leave that for future protocol extensions negotiated with > GET/SET_PROTOCOL_FEATURES ? I don't think negotiating such a basic protocol change is a good idea. cheers, Gerd
