Preferred layout for request/response structs

[Keiichi Watanabe <keiichiw@chromium.org>]

Hi, I'm designing virtio-video protocol [1] and thinking about its
structs' layouts.
The virtio-video protocol adopts the request-response model like
virtio-gpu and virtio-fs. While I looked at these two protocols, I
found they used different designs of having request headers.
So, Iâm wondering whatâs the best way of having the request / response
header for virtio-video.

On the one hand, virtio-gpu's structs for each control and response
contain the virtio_gpu_ctrl_hdr as one of fields:
struct virtio_gpu_get_edid {
  struct virtio_gpu_ctrl_hdr hdr;
  ...
};
struct virtio_gpu_resp_edid {
  struct virtio_gpu_ctrl_hdr hdr;
  ...
};

On the other hand, virtio-fs separates its header struct and request
body like the FUSE protocol:
struct fuse_in_header in;
union {
  struct fuse_read_in readin;
  ...
};

When we define a new protocol, which layout is preferred? I'd
especially like to know why virtio-gpu decided to use this design and
if the design is nice.

In the latest proposal of the virtio-video [1], we chose the same
design as virtio-gpu like:
struct virtio_video_resource_queue {
  struct virtio_video_cmd_hdr hdr;
  ...
};
struct virtio_video_resource_queue_resp {
  struct virtio_video_cmd_hdr hdr;
  ...
};
However, I thought it's a bit inconvenient that we cannot know the
actual size of a struct before its header. Actually, our device
implementation reads the header first to know the size and then reads
the whole struct including the header.
If it doesnât make any sense to follow the virtio-gpuâs header design,
Iâd like to separate the header and the command bodies and make the
driver send two structs per command:
struct virtio_video_cmd_hdr hdr; // contains what command follows
struct virtio_video_resource_queue {
    ...
};
struct virtio_video_resource_queue_resp {
  ...
};

Any types of comments are welcome! Thanks.

[1] https://markmail.org/message/dmw3pr4fuajvarth

Best regards,
Keiichi