On Thu, Jun 10, 2021 at 03:46:55PM +0800, Jason Wang wrote:
在 2021/6/10 下午3:23, 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.
Right, I wonder if we really need datagram consider the host to guest
communication is reliable.
(Note that I don't object it since vsock has already supported that,
just wonder its use cases)
Yep, it was the same concern I had :-)
Also because we're now adding SEQPACKET, which provides reliable
datagram support.
But IIUC the use case is the logging where you don't need a reliable
communication and you want to avoid to keep more open connections with
different guests.
So the server in the host can be pretty simple and doesn't have to
handle connections. It just waits for datagrams on a port.
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?
E.g the sendpage() and busy polling. And using UDP means qdiscs and
eBPF can work.
Thanks, I see!
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.
It depends on which level we want to share:
1) sharing codes
2) sharing devices
3) make vsock a protocol that is understood by the network core
We can start from 1), the low level tx/rx logic can be shared at both
virtio-net and vhost-net. For 2) we probably need some work on the
spec, probably with a new feature bit to demonstrate that it's a vsock
device not a ethernet device. Then if it is probed as a vsock device we
won't let packet to be delivered in the TCP/IP stack. For 3), it would
be even harder and I'm not sure it's worth to do that.
So in my opinion to unify them is not so simple, because vsock is not
really an ethernet device, but simply a socket.
We can start from sharing codes.
Yep, I agree, and maybe the mergeable buffer is a good starting point to
share code!
@Jiang, do you want to take a look of this possibility?
Thanks,
Stefano
