Re: [RFC PATCH v8 00/19] virtio/vsock: introduce SOCK_SEQPACKET support
From: Stefano Garzarella <sgarzare@redhat.com>
Date: 2021-04-22 08:46:53
Also in:
kvm, lkml, virtualization
From: Stefano Garzarella <sgarzare@redhat.com>
Date: 2021-04-22 08:46:53
Also in:
kvm, lkml, virtualization
On Wed, Apr 21, 2021 at 06:06:28PM +0300, Arseny Krasnov wrote:
On 21.04.2021 12:52, Stefano Garzarella wrote:quoted
On Tue, Apr 13, 2021 at 03:39:51PM +0300, Arseny Krasnov wrote:quoted
v7 -> v8: General changelog: - whole idea is simplified: channel now considered reliable, so SEQ_BEGIN, SEQ_END, 'msg_len' and 'msg_id' were removed. Only thing that is used to mark end of message is bit in 'flags' field of packet header: VIRTIO_VSOCK_SEQ_EOR. Packet with such bit set to 1 means, that this is last packet of message. - POSIX MSG_EOR support is removed, as there is no exact description how it works.It would be nice to support it, I'll try to see if I can find anything. I just reviewed the series. I think the most important things to fix are the `seqpacket_allow` stored in the struct virtio_transport that is wrong IMHO, and use cpu_to_le32()/le32_to_cpu() to access the flags.Thank You, i'll prepare next version. Main question is: does this approach(no SEQ_BEGIN, SEQ_END, 'msg_len' and 'msg_id') considered good? In this case it will be easier to prepare final version, because is smaller and more simple than previous logic. Also patch to spec will be smaller.
Yes, it's definitely much better than before. The only problem I see is that we add some overhead per fragment (header). We could solve that with the mergeable buffers that Jiang is considering for DGRAM. If we have that support, I think we could reuse it here as well, but it might be a next step. Thanks, Stefano