Re: [External] Re: vsock virtio: questions about supporting DGRAM type

On Fri, Feb 12, 2021 at 7:19 AM Arseny Krasnov
[off-list ref] wrote:

On 12.02.2021 12:02, Stefano Garzarella wrote:

quoted

Hi Jiang,

CCing Arseny who is working on SOCK_SEQPACKET support for virtio-vsock
[1].

On Thu, Feb 11, 2021 at 10:04:34PM -0800, Jiang Wang . wrote:

quoted

Hi guys,

I am working on supporting DGRAM type for virtio/vhost vsock. I
already did some work and a draft code is here (which passed my tests,
but still need some cleanup and only works from host to guest as of
now, will add host to guest soon):
https://github.com/Jiang1155/linux/commit/4e89736e0bce15496460ff411cb4694b143d1c3d
qemu changes are here:
https://github.com/Jiang1155/qemu/commit/7ab778801e3e8969ab98e44539943810a2fb03eb

Today, I just noticed that the Asias had an old version of virtio
which had both dgram and stream support, see this link:
https://kvm.vger.kernel.narkive.com/BMvH9eEr/rfc-v2-0-7-introduce-vm-sockets-virtio-transport#post1

But somehow, the dgram part seems never merged to upstream linux (the
stream part is merged). If so, does anyone know what is the reason for
this? Did we drop dgram support for some specific reason or the code
needs some improvement?

I wasn't involved yet in virtio-vsock development when Asias posted that
patches, so I don't know the exact reason.

Maybe could be related on how to handle the credit mechanism for a
connection-less sockets and how to manage the packet queue, if for
example no one is listening.

quoted

My current code differs from Asias' code in some ways. It does not use
credit and does not support fragmentation.  It basically adds two virt

If you don't use credit, do you have some threshold when you start to
drop packets on the RX side?

quoted

queues and re-uses the existing functions for tx and rx ( there is

This make sense, some time ago I was thinking about this and also came
to the conclusion that 2 new virtqueues were needed to handle DGRAM
traffic.

Sorry, but what is purpose of two new virt queues?

The two new virt queues will be dedicated for the DGRAM packets. Current
queues are used by STREAM (and your SEQPACKET) and the credit
mechanism is bound up with current queues. For DGRAM, the packets can be lost
and no need to use the credit based mechanism. Allocating two new queues
will make this simpler and DGRAM will not interfere with the STREAM
or SEQPACKET.

quoted

quoted

somewhat duplicate code for now, but I will try to make common
functions to reduce it). If we still want to support dgram in upstream
linux, which way do you guys recommend? If necessary, I can try to
base on Asias' old code and continue working on it. If there is
anything unclear, just let me know. Thanks.

A problem I see is how to handle multiple transports to support nested
VMs. Since the sockets are not connected, we can't assign them to a
single transport.

Arseny is working on SOCK_SEQPACKET [1], it's similar to DGRAM, but it
is connection oriented, so we can reuse most of the STREAM stuff and
also the credit mechanism.

Maybe you can reuse some of the Arseny's stuff to handle the
fragmentation.

Yes, just apply patchset to latest kernel. I've solved problem

with fragmentation at transport layer.

Got it. Thanks. I will check it out.

quoted

For the channel type (lossless) I think SEQPACKET makes more sense, but
if you have any use-cases for DGRAM and want to support it, you are
welcome to send patches and I will be happy to review them.

Thanks,
Stefano

[1]
https://lore.kernel.org/lkml/20210207151451.804498-1-arseny.krasnov@kaspersky.com/T/#m81d3ee4ccd54cd301b92c00b3b1bca6e7bc91fc9 (local)

Thanks, Arseny

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization