linux-kernel - Re: [RFC v1 0/6] virtio/vsock: introduce SOCK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210610072358.3fuvsahxec2sht4y@steredhat>
Date:   Thu, 10 Jun 2021 09:23:58 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     "Jiang Wang ." <jiang.wang@...edance.com>,
        virtualization@...ts.linux-foundation.org,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Arseny Krasnov <arseny.krasnov@...persky.com>,
        jhansen@...are.comments, cong.wang@...edance.com,
        Xiongchun Duan <duanxiongchun@...edance.com>,
        Yongji Xie <xieyongji@...edance.com>,
        柴稳 <chaiwen.cc@...edance.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Colin Ian King <colin.king@...onical.com>,
        Jorgen Hansen <jhansen@...are.com>,
        Andra Paraschiv <andraprs@...zon.com>,
        Norbert Slusarek <nslusarek@....net>,
        Lu Wei <luwei32@...wei.com>,
        Alexander Popov <alex.popov@...ux.com>, kvm@...r.kernel.org,
        Networking <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [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@...hat.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@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