? 2021/6/10 ??11:43, Jiang Wang . ??:> On Wed, Jun 9, 2021 at 6:51 PM Jason Wang <jasowang at redhat.com> 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). 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.> >>> 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 at huawei.com/ [2] https://lists.linuxfoundation.org/pipermail/virtualization/2018-November/039798.html [3] https://www.lkml.org/lkml/2020/1/16/2043 Thanks> >> Thanks >> >> >>> For those who prefer git repo, here is the link for the linux kernel? >>> https://github.com/Jiang1155/linux/tree/vsock-dgram-v1 >>> >>> qemu patch link: >>> https://github.com/Jiang1155/qemu/tree/vsock-dgram-v1 >>> >>> >>> To do: >>> 1. use skb when receiving packets >>> 2. support multiple transport >>> 3. support mergeable rx buffer >>> >>> >>> Jiang Wang (6): >>> virtio/vsock: add VIRTIO_VSOCK_F_DGRAM feature bit >>> virtio/vsock: add support for virtio datagram >>> vhost/vsock: add support for vhost dgram. >>> vsock_test: add tests for vsock dgram >>> vhost/vsock: add kconfig for vhost dgram support >>> virtio/vsock: add sysfs for rx buf len for dgram >>> >>> drivers/vhost/Kconfig | 8 + >>> drivers/vhost/vsock.c | 207 ++++++++-- >>> include/linux/virtio_vsock.h | 9 + >>> include/net/af_vsock.h | 1 + >>> .../trace/events/vsock_virtio_transport_common.h | 5 +- >>> include/uapi/linux/virtio_vsock.h | 4 + >>> net/vmw_vsock/af_vsock.c | 12 + >>> net/vmw_vsock/virtio_transport.c | 433 ++++++++++++++++++--- >>> net/vmw_vsock/virtio_transport_common.c | 184 ++++++++- >>> tools/testing/vsock/util.c | 105 +++++ >>> tools/testing/vsock/util.h | 4 + >>> tools/testing/vsock/vsock_test.c | 195 ++++++++++ >>> 12 files changed, 1070 insertions(+), 97 deletions(-) >>>
Stefano Garzarella
2021-Jun-10 07:23 UTC
[RFC v1 0/6] virtio/vsock: introduce SOCK_DGRAM support
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 at redhat.com> 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 at huawei.com/ >[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