On 22.04.2021 11:46, Stefano Garzarella wrote:

On Wed, Apr 21, 2021 at 06:06:28PM +0300, Arseny Krasnov wrote:

quoted

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 are talking about receive, i think, i can reuse merge logic for

stream sockets, the only difference is that buffers are mergeable

until previous EOR(e.g. previous message) bit is found in rx queue.

If we have that support, I think we could reuse it here as well, but it 
might be a next step.

Thanks,
Stefano