Messages in this thread | | | Subject | Re: [RFC v1 0/6] virtio/vsock: introduce SOCK_DGRAM support | From | Jason Wang <> | Date | Thu, 10 Jun 2021 12:02:35 +0800 |
| |
在 2021/6/10 上午11:43, Jiang Wang . 写道: > On Wed, Jun 9, 2021 at 6:51 PM Jason Wang <jasowang@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@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(-) >>>
| |