Re: [PATCH v7] virtio-vsock: Add support for multi devices

On Fri, Jun 13, 2025 at 4:46 PM Xuewei Niu <[email protected]> wrote:
>
> > On Fri, 13 Jun 2025 at 06:57, Xuewei Niu <[email protected]> wrote:
> > >
> > > > On Sat, Apr 12, 2025 at 10:39 PM Xuewei Niu <[email protected]> wrote:
> > > > >
> > > > > This patch brings a new feature, called "multi devices", to the virtio
> > > > > vsock. It introduces a "VIRTIO_VSOCK_F_MULTI_DEVICES" feature bit, and a
> > > > > "device_order" field to the config for the virtio vsock.
> > > > >
> > > > > == Motivition ==
> > > > >
> > > > > Vsock is a lightweight and widely used data exchange mechanism between host
> > > > > and guest. Currently, the virtio-vsock only supports one device, resulting
> > > > > in the inability to enable more than one backend.
> > > >
> > > > I wonder which part of the spec forbids more than one device.
> > >
> > > No. The spec, however, is designed for a single device, and lacks some
> > > specifications for multiple devices.
> > >
> > > For example, we should have a mechanism to select a device from all to
> > > communicate with a peer.

I wonder if this is a:

1) mechanism that needs to be mandated by the device
2) a policy that is allowed to be tweaked by the user as TCP/IP did

(Note anyhow the driver can override what the device suggests...)


> > >
> > > This patch introduces a new feature bit "VIRTIO_VSOCK_F_MULTI_DEVICES", and
> > > involves some modifications to the config space, device & driver norms.
> >
> > Maybe we should think a better name to avoid confusion, like "F_DEVICE_ORDER".
> > I'm not good at name, so if others are better suggestion, they are welcome.
>
> Naming things is tough for me, too. I'm good with "F_DEVICE_ORDER", and
> will update it in the next. I am still open to other suggestions.

If we agree on the idea, I agree we need a better name.

Thanks

>
> Thanks,
> Xuewei
>
> > >
> > > > > For instance, two devices
> > > > > are required: one to transfer data to the VMM via virtio-vsock, and another
> > > > > to a user process via vhost-user-vsock.
> > > > >
> > > > > Apart from that, a side gain is that theoretically the performance might be
> > > > > improved since each device has its own queue. But it varies depending on
> > > > > the implementation.
> > > >
> > > > It could implement multiqueue anyhow.
> > > >
> > > > Thanks
> > >
> > > Yes, indeed. As we discussed before, I marked this as a side gain. And
> > > @Stefano said that the community has a plan to implement multiqueue for
> > > vsock.
> >
> > I'm not sure there is a plan, but yeah, we should do it some day.
> > As I mention in the previous email, I'd remove any reference to performance.
> >
> > I'd just talk about a mechanism to select a default out device, when
> > the source socket is not bound to any address, like a default gateway.
> >
> > Thanks,
> > Stefano
> >
> > > The foundational goal of this patch is to enable vsock to support
> > > multiple backends.
> > >
> > > Thanks,
> > > Xuewei
>