All of lore.kernel.org
 help / color / mirror / Atom feed
From: beshleman.devbox@gmail.com
To: mst@redhat.com, cohuck@redhat.com, virtio-comment@lists.oasis-open.org
Cc: cong.wang@bytedance.com, duanxiongchun@bytedance.com,
	jiang.wang@bytedance.com,
	virtualization@lists.linux-foundation.org,
	xieyongji@bytedance.com, chaiwen.cc@bytedance.com,
	stefanha@redhat.com, asias@redhat.com,
	arseny.krasnov@kaspersky.com, jhansen@vmware.com,
	bobby.eshleman@bytedance.com
Subject: [PATCH v5 1/2] virtio-vsock: add description for datagram type
Date: Thu, 24 Feb 2022 21:57:31 +0000	[thread overview]
Message-ID: <20220224215732.2426614-2-beshleman.devbox@gmail.com> (raw)
In-Reply-To: <20220224215732.2426614-1-beshleman.devbox@gmail.com>

From: Jiang Wang <jiang.wang@bytedance.com>

Add supports for datagram type for virtio-vsock. Datagram
sockets are connectionless and unreliable. To avoid contention
with stream and other sockets, add two more virtqueues and
a new feature bit to identify if those two new queues exist or not.

Also add descriptions for resource management of datagram, which
does not use the existing credit update mechanism associated with
stream sockets.

Signed-off-by: Jiang Wang <jiang.wang@bytedance.com>
Signed-off-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
---

V2: Addressed the comments for the previous version.
V3: Add description for the mergeable receive buffer.
V4: Add a feature bit for stream and reserver a bit for seqpacket.
    Fix mrg_rxbuf related sentences.
V5: Rebase onto head (change to more nicely accompany seqpacket changes).
    Remove statement about no feature bits being set (already made by seqpacket patches).
    Clarify \field{type} declaration.
    Use words "sender/receiver" instead of "tx/rx" for clarity, and other prose changes.
    Directly state that full buffers result in dropped packets.
    Change verbs to present tense.
    Clarify if-else pairs (e.g., "If XYZ is negotiated" is followed by "If XYZ
    is not negotiated" instead of "Otherwise").
    Mergeable buffer changes are split off into a separate patch.

 virtio-vsock.tex | 63 +++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 53 insertions(+), 10 deletions(-)

diff --git a/virtio-vsock.tex b/virtio-vsock.tex
index d79984d..1a66a1b 100644
--- a/virtio-vsock.tex
+++ b/virtio-vsock.tex
@@ -9,11 +9,26 @@ \subsection{Device ID}\label{sec:Device Types / Socket Device / Device ID}
 
 \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues}
 \begin{description}
-\item[0] rx
-\item[1] tx
+\item[0] stream rx
+\item[1] stream tx
+\item[2] datagram rx
+\item[3] datagram tx
+\item[4] event
+\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}
 
 If no feature bit is set, only stream socket type is supported.
@@ -23,6 +38,7 @@ \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits}
 \begin{description}
 \item[VIRTIO_VSOCK_F_STREAM (0)] stream socket type is supported.
 \item[VIRTIO_VSOCK_F_SEQPACKET (1)] seqpacket socket type is supported.
+\item[VIRTIO_VSOCK_F_DGRAM (2)] datagram socket type is supported.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout}
@@ -109,6 +125,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.
@@ -142,18 +161,22 @@ \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 stream and seqpacket sockets are supported. \field{type} is 1 (VIRTIO_VSOCK_TYPE_STREAM)
-for stream socket types, and 2 (VIRTIO_VSOCK_TYPE_SEQPACKET) for seqpacket socket types.
+Currently stream, seqpacket, and dgram sockets are supported. \field{type} is 1 (VIRTIO_VSOCK_TYPE_STREAM)
+for stream socket types, 2 (VIRTIO_VSOCK_TYPE_SEQPACKET) for seqpacket socket types, and 3 (VIRTIO_VSOCK_TYPE_DGRAM) for dgram socket types.
 
 \begin{lstlisting}
 #define VIRTIO_VSOCK_TYPE_STREAM    1
 #define VIRTIO_VSOCK_TYPE_SEQPACKET 2
+#define VIRTIO_VSOCK_TYPE_DGRAM     3
 \end{lstlisting}
 
 Stream sockets provide in-order, guaranteed, connection-oriented delivery
 without message boundaries. Seqpacket sockets provide in-order, guaranteed,
 connection-oriented delivery with message and record 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
@@ -170,7 +193,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.
@@ -178,22 +201,32 @@ \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
+into two parts: senders and receivers. For senders, the packet is dropped if the
+virtqueue is full. For receivers, the packet is dropped if there is no space
+in the receive buffer.
+
 \drivernormative{\paragraph}{Device Operation: Buffer Space Management}{Device Types / Socket Device / Device Operation / Buffer Space Management}
-VIRTIO_VSOCK_OP_RW data packets MUST only be transmitted when the peer has
-sufficient free buffer space for the payload.
+For stream sockets, VIRTIO_VSOCK_OP_RW data packets MUST only be transmitted when the peer has
+sufficient free buffer space for the payload. For dgram sockets, VIRTIO_VSOCK_OP_RW data packets
+MAY be transmitted when the peer rx buffer is full. Then the packet will be dropped by the peer,
+and driver will not get any notification.
 
 All packets associated with a stream flow MUST contain valid information in
 \field{buf_alloc} and \field{fwd_cnt} fields.
 
 \devicenormative{\paragraph}{Device Operation: Buffer Space Management}{Device Types / Socket Device / Device Operation / Buffer Space Management}
-VIRTIO_VSOCK_OP_RW data packets MUST only be transmitted when the peer has
-sufficient free buffer space for the payload.
+For stream sockets, VIRTIO_VSOCK_OP_RW data packets MUST only be transmitted when the peer has
+sufficient free buffer space for the payload. For dgram sockets, VIRTIO_VSOCK_OP_RW data packets
+MAY be transmitted when the peer rx buffer is full. Then the packet will be dropped by the peer,
+and the device will not get any notification.
 
 All packets associated with a stream flow MUST contain valid information in
 \field{buf_alloc} and \field{fwd_cnt} fields.
 
 \subsubsection{Receive and Transmit}\label{sec:Device Types / Socket Device / Device Operation / Receive and Transmit}
-The driver queues outgoing packets on the tx virtqueue and incoming packet
+The driver queues outgoing packets on the tx virtqueue and allocates incoming packet
 receive buffers on the rx virtqueue. Packets are of the following form:
 
 \begin{lstlisting}
@@ -206,6 +239,8 @@ \subsubsection{Receive and Transmit}\label{sec:Device Types / Socket Device / De
 Virtqueue buffers for outgoing packets are read-only. Virtqueue buffers for
 incoming packets are write-only.
 
+When transmitting packets to the device, \field{num_buffers} is not used.
+
 \drivernormative{\paragraph}{Device Operation: Receive and Transmit}{Device Types / Socket Device / Device Operation / Receive and Transmit}
 
 The \field{guest_cid} configuration field MUST be used as the source CID when
@@ -274,6 +309,14 @@ \subsubsection{Seqpacket Sockets}\label{sec:Device Types / Socket Device / Devic
 #define VIRTIO_VSOCK_SEQ_EOR (1 << 1)
 \end{lstlisting}
 
+\subsubsection{Datagram Sockets}\label{sec:Device Types / Socket Device / Device Operation / Datagram Sockets}
+
+Datagram (dgram) sockets are connectionless and unreliable. The sender just sends
+a message to the peer and hopes it will be delivered. A VIRTIO_VSOCK_OP_RST reply is sent if
+a receiving socket does not exist on the destination.
+If the transmission or receiving buffers are full, the packets
+are dropped.
+
 \subsubsection{Device Events}\label{sec:Device Types / Socket Device / Device Operation / Device Events}
 
 Certain events are communicated by the device to the driver using the event
-- 
2.11.0


  reply	other threads:[~2022-02-24 21:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-28  4:01 [RFC v4] virtio-vsock: add description for datagram type Jiang Wang
2021-05-28  4:01 ` [virtio-comment] " Jiang Wang
2021-06-07 18:45 ` Jiang Wang .
2021-06-07 18:45   ` [virtio-comment] " Jiang Wang .
2021-06-08 13:46 ` Stefano Garzarella
2021-06-08 13:46   ` [virtio-comment] " Stefano Garzarella
2021-06-09  4:22   ` [External] " Jiang Wang .
2021-06-09  4:22     ` [virtio-comment] " Jiang Wang .
2021-06-09  7:17     ` Stefano Garzarella
2021-06-09  7:17       ` [virtio-comment] " Stefano Garzarella
2021-06-10  3:31       ` Jiang Wang .
2021-06-10  3:31         ` [virtio-comment] " Jiang Wang .
2021-06-10  6:56         ` Stefano Garzarella
2021-06-10  6:56           ` [virtio-comment] " Stefano Garzarella
2022-02-24 21:57 ` [PATCH v5 0/2] Support vsock datagram and mergeable buffers beshleman.devbox
2022-02-24 21:57   ` beshleman.devbox [this message]
2022-02-24 21:57   ` [PATCH v5 2/2] virtio-vsock: add mergeable buffer feature bit beshleman.devbox
2022-02-24 22:15 ` [PATCH v5 0/2] Support vsock datagram and mergeable buffers beshleman.devbox
2022-02-24 22:15   ` [PATCH v5 1/2] virtio-vsock: add description for datagram type beshleman.devbox
2022-03-02 16:09     ` [virtio-comment] " Stefano Garzarella
2022-03-02 16:09       ` Stefano Garzarella
2022-03-03  3:29       ` Bobby Eshleman
2022-03-03  7:15         ` Michael S. Tsirkin
2022-03-03  7:15           ` Michael S. Tsirkin
2022-03-05  1:25           ` Bobby Eshleman
2022-03-06 10:17             ` Michael S. Tsirkin
2022-03-06 10:17               ` Michael S. Tsirkin
2022-03-03 10:23         ` Stefano Garzarella
2022-03-03 10:23           ` Stefano Garzarella
2022-03-05  1:25           ` Bobby Eshleman
2022-03-03 11:41         ` Michael S. Tsirkin
2022-03-03 11:41           ` Michael S. Tsirkin
2022-03-07 17:41           ` Bobby Eshleman
2022-02-24 22:15   ` [PATCH v5 2/2] virtio-vsock: add mergeable buffer feature bit beshleman.devbox
2022-03-02 16:19     ` [virtio-comment] " Stefano Garzarella
2022-03-02 16:19       ` Stefano Garzarella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220224215732.2426614-2-beshleman.devbox@gmail.com \
    --to=beshleman.devbox@gmail.com \
    --cc=arseny.krasnov@kaspersky.com \
    --cc=asias@redhat.com \
    --cc=bobby.eshleman@bytedance.com \
    --cc=chaiwen.cc@bytedance.com \
    --cc=cohuck@redhat.com \
    --cc=cong.wang@bytedance.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=jhansen@vmware.com \
    --cc=jiang.wang@bytedance.com \
    --cc=mst@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.