Re: [RFC v1 0/6] virtio/vsock: introduce SOCK_DGRAM support

[Stefano Garzarella]

On Thu, Jun 10, 2021 at 12:02:35PM +0800, Jason Wang wrote:
> 在 2021/6/10 上午11:43, Jiang Wang . 写道:
> > On Wed, Jun 9, 2021 at 6:51 PM Jason Wang <jasowang@xxxxxxxxxx> wrote:
> > > 在 2021/6/10 上午7:24, Jiang Wang 写道:
> > > > This patchset implements support of SOCK_DGRAM for virtio
> > > > transport.
> > > >
> > > > Datagram sockets are connectionless and unreliable. To avoid unfair contention
> > > > with stream and other sockets, add two more virtqueues and
> > > > a new feature bit to indicate if those two new queues exist or not.
> > > >
> > > > Dgram does not use the existing credit update mechanism for
> > > > stream sockets. When sending from the guest/driver, sending packets
> > > > synchronously, so the sender will get an error when the virtqueue is 
> > > > full.
> > > > When sending from the host/device, send packets asynchronously
> > > > because the descriptor memory belongs to the corresponding QEMU
> > > > process.
> > >
> > > What's the use case for the datagram vsock?
> > One use case is for non critical info logging from the guest
> > to the host, such as the performance data of some applications.
>
>
> Anything that prevents you from using the stream socket?
>
>
> > It can also be used to replace UDP communications between
> > the guest and the host.
>
>
> Any advantage for VSOCK in this case? Is it for performance (I guess 
> not since I don't exepct vsock will be faster).

I think the general advantage to using vsock are for the guest agents 
that potentially don't need any configuration.

> An obvious drawback is that it breaks the migration. Using UDP you can 
> have a very rich features support from the kernel where vsock can't.

Thanks for bringing this up!
What features does UDP support and datagram on vsock could not support?

> > > > The virtio spec patch is here:
> > > > https://www.spinics.net/lists/linux-virtualization/msg50027.html
> > >
> > > Have a quick glance, I suggest to split mergeable rx buffer into an
> > > separate patch.
> > Sure.
> >
> > > But I think it's time to revisit the idea of unifying the virtio-net 
> > > and
> > > virtio-vsock. Otherwise we're duplicating features and bugs.
> > For mergeable rxbuf related code, I think a set of common helper
> > functions can be used by both virtio-net and virtio-vsock. For other
> > parts, that may not be very beneficial. I will think about more.
> >
> > If there is a previous email discussion about this topic, could you 
> > send me
> > some links? I did a quick web search but did not find any related
> > info. Thanks.
>
>
> We had a lot:
>
> [1] 
> https://patchwork.kernel.org/project/kvm/patch/5BDFF537.3050806@xxxxxxxxxx/
> [2] 
> https://lists.linuxfoundation.org/pipermail/virtualization/2018-November/039798.html
> [3] https://www.lkml.org/lkml/2020/1/16/2043

When I tried it, the biggest problem that blocked me were all the 
features strictly related to TCP/IP stack and ethernet devices that 
vsock device doesn't know how to handle: TSO, GSO, checksums, MAC, napi, 
xdp, min ethernet frame size, MTU, etc.

So in my opinion to unify them is not so simple, because vsock is not 
really an ethernet device, but simply a socket.

But I fully agree that we shouldn't duplicate functionality and code, so 
maybe we could find those common parts and create helpers to be used by 
both.

Thanks,
Stefano