On 22.04.2021 11:46, Stefano Garzarella wrote: > On Wed, Apr 21, 2021 at 06:06:28PM +0300, Arseny Krasnov wrote: >> On 21.04.2021 12:52, Stefano Garzarella wrote: >>> On Tue, Apr 13, 2021 at 03:39:51PM +0300, Arseny Krasnov wrote: >>>> 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 > >
