Thread (43 messages) 43 messages, 2 authors, 2021-04-22

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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help