> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Wednesday, May 30, 2018 10:57 AM
> On Tue, May 29, 2018 at 01:38:33PM +0000, Stojaczyk, DariuszX wrote:
> >
> >
> > > -----Original Message-----
> > > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > Sent: Friday, May 25, 2018 12:06 PM
> > > On Fri, May 18, 2018 at 03:01:05PM +0200, Dariusz Stojaczyk wrote:
> > > > +struct rte_vhost2_msg {
> > > > + uint32_t id;
> > >
> > > Is this what the vhost-user specification calls the "request type"?
> > > I suggest following the vhost-user spec terminology.
> > >
> > > > + uint32_t flags;
> > > > + uint32_t size; /**< The following payload size. */
> > > > + void *payload;
> > > > + int fds[RTE_VHOST2_MEMORY_MAX_NREGIONS];
> > >
> > > Is it necessary to expose file descriptor passing in the API?
> > > virtio-vhost-user doesn't have file descriptor passing, so it's best
> > > if this can be hidden inside rte_vhost2.
> >
> > So it's another argument for not exposing raw message handling to the
> user.
> > If there's some backend-specific vhost-user message in future that
> contains an fd, it will need a set of new abstractions to work with virtio-
> vhost-user anyway.
> > I guess I'll get back the original custom_msg idea from V1.
>
> Hold on, have you looked at the device-specific messages defined in the
> vhost-user spec? Do any of them even pass resources (file descriptors)?
There's at least VHOST_USER_NVME_SET_CQ_CALL (currently in review, not present
in master yet). Vhost-nvme is a one big hack that doesn't use any virtqueues,
so it has its own message for callfd.
