>
>so I assume the virtqueues for tx/rx should be
>continuous? I can try to put the new queues at the end and see if it
>works or not.
>
>btw, my qemu change is here:
>https://github.com/Jiang1155/qemu/commit/6307aa7a0c347905a31f3ca6577923e2f6dd9d84
>
>> >+\end{description}
>> >+The virtio socket device uses 5 queues if feature bit VIRTIO_VSOCK_F_DRGAM is set. Otherwise, it
>> >+only uses 3 queues, as the following.
>> >+
>> >+\begin{description}
>> >+\item[0] stream rx
>> >+\item[1] stream tx
>> > \item[2] event
>> > \end{description}
>> >
>> >+When behavior differs between stream and datagram rx/tx virtqueues
>> >+their full names are used. Common behavior is simply described in
>> >+terms of rx/tx virtqueues and applies to both stream and datagram
>> >+virtqueues.
>> >+
>> > \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits}
>> >
>> >-There are currently no feature bits defined for this device.
>> >+\begin{description}
>> >+\item[VIRTIO_VSOCK_F_STREAM (0)] Device has support for stream socket type.
>> >+\end{description}
>> >+
>> >+\begin{description}
>> >+\item[VIRTIO_VSOCK_F_DGRAM (2)] Device has support for datagram socket
>> >type.
>> >+\end{description}
>> >+
>> >+\begin{description}
>> >+\item[VIRTIO_VSOCK_F_MRG_RXBUF (3)] Driver can merge receive buffers.
>> >+\end{description}
>> >+
>> >+If no feature bits are defined, then assume only VIRTIO_VSOCK_F_STREAM
>> >is set.
>>
>> I'd say more like socket streams are supported, without reference to the
>> feature bit, something like: "If no feature bits are defined, then
>> assume device only supports stream socket type."
>>
>OK.
>
>> >
>> > \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout}
>> >
>> >@@ -64,6 +91,8 @@ \subsection{Device Operation}\label{sec:Device Types / Socket Device / Device Op
>> >
>> > Packets transmitted or received contain a header before the payload:
>> >
>> >+If feature VIRTIO_VSOCK_F_MRG_RXBUF is not negotiated, use the following header.
>> >+
>> > \begin{lstlisting}
>> > struct virtio_vsock_hdr {
>> > le64 src_cid;
>> >@@ -79,6 +108,15 @@ \subsection{Device Operation}\label{sec:Device Types / Socket Device / Device Op
>> > };
>> > \end{lstlisting}
>> >
>> >+If feature VIRTIO_VSOCK_F_MRG_RXBUF is negotiated, use the following header.
>> >+\begin{lstlisting}
>> >+struct virtio_vsock_hdr_mrg_rxbuf {
>> >+ struct virtio_vsock_hdr hdr;
>> >+ le16 num_buffers;
>> >+};
>> >+\end{lstlisting}
>> >+
>> >+
>> > The upper 32 bits of src_cid and dst_cid are reserved and zeroed.
>> >
>> > Most packets simply transfer data but control packets are also used for
>> >@@ -107,6 +145,9 @@ \subsection{Device Operation}\label{sec:Device Types / Socket Device / Device Op
>> >
>> > \subsubsection{Virtqueue Flow Control}\label{sec:Device Types / Socket Device / Device Operation / Virtqueue Flow Control}
>> >
>> >+Flow control applies to stream sockets; datagram sockets do not have
>> >+flow control.
>> >+
>> > The tx virtqueue carries packets initiated by applications and replies to
>> > received packets. The rx virtqueue carries packets initiated by the device and
>> > replies to previously transmitted packets.
>> >@@ -140,12 +181,15 @@ \subsubsection{Addressing}\label{sec:Device Types / Socket Device / Device Opera
>> > consists of a (cid, port number) tuple. The header fields used for this are
>> > \field{src_cid}, \field{src_port}, \field{dst_cid}, and \field{dst_port}.
>> >
>> >-Currently only stream sockets are supported. \field{type} is 1 for
>> >stream
>> >-socket types.
>> >+Currently stream and datagram (dgram) sockets are supported. \field{type} is 1 for stream
>> >+socket types. \field{type} is 3 for dgram socket types.
>>
>> When Arseny's change will merged, we can define and use
>> VIRTIO_VSOCK_TYPE_DGRAM,.
>
>Sure.
>> >
>> > Stream sockets provide in-order, guaranteed, connection-oriented
>> > delivery
>> > without message boundaries.
>> >
>> >+Datagram sockets provide unordered, unreliable, connectionless
>> >messages
>> >+with message boundaries and a maximum length.
>> >+
>> > \subsubsection{Buffer Space Management}\label{sec:Device Types / Socket Device / Device Operation / Buffer Space Management}
>> > \field{buf_alloc} and \field{fwd_cnt} are used for buffer space
>> > management of
>> > stream sockets. The guest and the device publish how much buffer space is
>> >@@ -162,7 +206,7 @@ \subsubsection{Buffer Space Management}\label{sec:Device Types / Socket Device /
>> > u32 peer_free = peer_buf_alloc - (tx_cnt - peer_fwd_cnt);
>> > \end{lstlisting}
>> >
>> >-If there is insufficient buffer space, the sender waits until virtqueue buffers
>> >+For stream sockets, if there is insufficient buffer space, the sender waits until virtqueue buffers
>> > are returned and checks \field{buf_alloc} and \field{fwd_cnt} again. Sending
>> > the VIRTIO_VSOCK_OP_CREDIT_REQUEST packet queries how much buffer space is
>> > available. The reply to this query is a VIRTIO_VSOCK_OP_CREDIT_UPDATE packet.
>> >@@ -170,24 +214,55 @@ \subsubsection{Buffer Space Management}\label{sec:Device Types / Socket Device /
>> > previously receiving a VIRTIO_VSOCK_OP_CREDIT_REQUEST packet. This allows
>> > communicating updates any time a change in buffer space occurs.
>> >
>> >+Unlike stream sockets, dgram sockets do not use VIRTIO_VSOCK_OP_CREDIT_UPDATE or
>> >+VIRTIO_VSOCK_OP_CREDIT_REQUEST packets. The dgram buffer management
>> >+is split to two parts: tx side and rx side. For the tx side, if the
>>
>> Maybe better to use sender and receiver, since we use tx and rx to
>> identify the queues.
>
>OK.
>
>> >+virtqueue is full, the packet will be dropped.
>> >+For the rx side, dgram also uses the \field{buf_alloc}. If it is full, the packet
>> >+is dropped by the receiver.
>>
>> This sentence is a bit unclear.
>> `buf_alloc` for stream socket is used to inform the other peer about the
>> receive buffer space. In this case we are using the local information,
>> so there is no need to refer to `buf_alloc`. We can write something
>> like: "The packet is dropped by the receiver if there is no space in the
>> receive buffer".
>
>OK.
>
>> >+
>> >+\drivernormative{\paragraph}{Device Operation: Buffer Space Management}{Device Types / Socket Device / Device Operation / Setting Up Receive Buffers}
>> >+\begin{itemize}
>> >+\item If VIRTIO_VSOCK_F_MRG_RXBUF is not negotiated, the driver SHOULD populate the receive queue(s)
>> >+ with buffers of at least 1526 bytes for stream sockets and 4096
>> >bytes for datagram sockets.
>>
>> Where does 1526 come from?
>
>No specific reason. Any recommendations?
>
>> We're adding a requirement for socket streams that wasn't there until
>> now.
>
>This is only when mergeable rxbuf bit is used. I think before this, the stream
>rx buf should be at least bigger than the pkt header. We just did not put that
>into the spec.
Mmm, I'm confused now. The statement says "If VIRTIO_VSOCK_F_MRG_RXBUF
is not negotiated"
^
