Re: [virtio-comment] [RFC PATCH v4 2/2] virtio-vsock: SOCK_SEQPACKET description

[Stefano Garzarella <sgarzare@redhat.com>]

On Mon, Mar 29, 2021 at 08:33:27PM +0300, Arseny Krasnov wrote:
> On 29.03.2021 19:11, Stefan Hajnoczi wrote:
> > On Fri, Mar 26, 2021 at 12:02:50PM +0300, Arseny Krasnov wrote:
> > > This adds description of SOCK_SEQPACKET socket type
> > > support for virtio-vsock.
> > >
> > > Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
> > > ---
> > >  virtio-vsock.tex | 65 +++++++++++++++++++++++++++++++++++++++++++-----
> > >  1 file changed, 59 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/virtio-vsock.tex b/virtio-vsock.tex
> > > index ad57f9d..c366de7 100644
> > > --- a/virtio-vsock.tex
> > > +++ b/virtio-vsock.tex
> > > @@ -17,6 +17,10 @@ \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues}
> > >  \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits}
> > >
> > >  There are currently no feature bits defined for this device.
> > ^ This line is now out of date :)
> Ack
> > > +\begin{description}
> > > +\item VIRTIO_VSOCK_F_SEQPACKET (0) SOCK_SEQPACKET socket type is
> > > +    supported.
> > > +\end{description}
> > >
> > >  \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout}
> > >
> > > @@ -98,6 +102,10 @@ \subsection{Device Operation}\label{sec:Device Types / Socket Device / Device Op
> > >  #define VIRTIO_VSOCK_OP_CREDIT_UPDATE  6
> > >  /* Request the peer to send the credit info to us */
> > >  #define VIRTIO_VSOCK_OP_CREDIT_REQUEST 7
> > > +/* Message begin for SOCK_SEQPACKET */
> > > +#define VIRTIO_VSOCK_OP_SEQ_BEGIN      8
> > > +/* Message end for SOCK_SEQPACKET */
> > > +#define VIRTIO_VSOCK_OP_SEQ_END        9
> > The struct virtio_vsock_hdr->flags field is le32 and currently unused.
> > Could 24 bits be used for a unique message id and 8 bits for flags? 1
> > flag bit could be used for end-of-message and the remaining 7 bits could
> > be reserved. That way SEQ_BEGIN and SEQ_END are not necessary.  
> > Pressure
> > on the virtqueue would be reduced and performance should be comparable
> > to SOCK_STREAM.
>
> Well, my first versions of SOCK_SEQPACKET implementation, worked
> something like this: i used flags field of header as length of whole
> message. I discussed it with Stefano Garzarella, and he told that it 
> will
> be better to use special "header" in packet's payload, to keep some
> SOCK_SEQPACKET specific data, instead of reusing packet's header
> fields.

IIRC in the first implementation SEQ_BEGIN was an empty message and we 
didn't added the msg_id yet. So since we needed to carry both id and 
total length, I suggested to use the payload to put these extra 
information.

IIUC what Stefan is suggesting is a bit different and I think it should 
be cool to implement: we can remove the boundary packets, use only 8 
bits for the flags, and add a new field to reuse the 24 unused bits, 
maybe also 16 bits would be enough.
At that point we will only use the EOR flag to know the last packet.

The main difference will be that the receiver will know the total size 
only when the last packet is received.

Do you see any issue on that approach?

Thanks,
Stefano