From: "Michael S. Tsirkin" <mst@redhat.com> To: Arseny Krasnov <arseny.krasnov@kaspersky.com> Cc: Andra Paraschiv <andraprs@amazon.com>, Jeff Vander Stoep <jeffv@google.com>, cohuck@redhat.com, Colin Ian King <colin.king@canonical.com>, oxffffaa@gmail.com, Norbert Slusarek <nslusarek@gmx.net>, Stefan Hajnoczi <stefanha@redhat.com>, virtio-comment@lists.oasis-open.org, Jakub Kicinski <kuba@kernel.org>, Alexander Popov <alex.popov@linux.com>, virtualization@lists.linux-foundation.org, "David S. Miller" <davem@davemloft.net>, Jorgen Hansen <jhansen@vmware.com> Subject: Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description Date: Tue, 13 Apr 2021 09:10:11 -0400 [thread overview] Message-ID: <20210413090642-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20210413125333.3419315-1-arseny.krasnov@kaspersky.com> On Tue, Apr 13, 2021 at 03:53:29PM +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 | 26 +++++++++++++++++++++----- > 1 file changed, 21 insertions(+), 5 deletions(-) > > diff --git a/virtio-vsock.tex b/virtio-vsock.tex > index ad57f9d..00e59cc 100644 > --- a/virtio-vsock.tex > +++ b/virtio-vsock.tex > @@ -16,7 +16,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. > +\begin{description} > +\item VIRTIO_VSOCK_F_SEQPACKET (0) SOCK_SEQPACKET socket type is > + supported. Does it make sense to only support seqpacket and not stream? I am guessing not since seqpacket is more or less a superset ... > +\end{description} > > \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout} > > @@ -135,15 +138,17 @@ \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 (VIRTIO_VSOCK_TYPE_STREAM) > -for stream socket types. > +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. > > \begin{lstlisting} > -#define VIRTIO_VSOCK_TYPE_STREAM 1 > +#define VIRTIO_VSOCK_TYPE_STREAM 1 > +#define VIRTIO_VSOCK_TYPE_SEQPACKET 2 > \end{lstlisting} > > Stream sockets provide in-order, guaranteed, connection-oriented delivery > -without message boundaries. > +without message boundaries. Seqpacket sockets provide in-order, guaranteed, > +connection-oriented delivery with message boundaries. > > \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 > @@ -244,6 +249,17 @@ \subsubsection{Stream Sockets}\label{sec:Device Types / Socket Device / Device O > destination) address tuple for a new connection while the other peer is still > processing the old connection. > > +\subsubsection{Seqpacket Sockets}\label{sec:Device Types / Socket Device / Device Operation / Seqpacket Sockets} > + > +\paragraph{Message boundaries}\label{sec:Device Types / Socket Device / Device Operation / Seqpacket Sockets / Message boundaries} > + > +To provide message boundaries, last RW packet of each message has VIRTIO_VSOCK_SEQ_EOR > +bit set in the \field{flags} of packet's header. > + > +\begin{lstlisting} > +#define VIRTIO_VSOCK_SEQ_EOR 1 > +\end{lstlisting} Problem is, where is device going to hold this boundary? Currently device discards the header just keeping the payload around. I suspect we need to have some kind of header per message maintained by the device and accounted for as part of the the credit accounting. > + > \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.25.1 _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Arseny Krasnov <arseny.krasnov@kaspersky.com> Cc: cohuck@redhat.com, virtio-comment@lists.oasis-open.org, Stefan Hajnoczi <stefanha@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, Jason Wang <jasowang@redhat.com>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Jorgen Hansen <jhansen@vmware.com>, Colin Ian King <colin.king@canonical.com>, Norbert Slusarek <nslusarek@gmx.net>, Andra Paraschiv <andraprs@amazon.com>, Jeff Vander Stoep <jeffv@google.com>, Alexander Popov <alex.popov@linux.com>, virtualization@lists.linux-foundation.org, oxffffaa@gmail.com Subject: [virtio-comment] Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description Date: Tue, 13 Apr 2021 09:10:11 -0400 [thread overview] Message-ID: <20210413090642-mutt-send-email-mst@kernel.org> (raw) In-Reply-To: <20210413125333.3419315-1-arseny.krasnov@kaspersky.com> On Tue, Apr 13, 2021 at 03:53:29PM +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 | 26 +++++++++++++++++++++----- > 1 file changed, 21 insertions(+), 5 deletions(-) > > diff --git a/virtio-vsock.tex b/virtio-vsock.tex > index ad57f9d..00e59cc 100644 > --- a/virtio-vsock.tex > +++ b/virtio-vsock.tex > @@ -16,7 +16,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. > +\begin{description} > +\item VIRTIO_VSOCK_F_SEQPACKET (0) SOCK_SEQPACKET socket type is > + supported. Does it make sense to only support seqpacket and not stream? I am guessing not since seqpacket is more or less a superset ... > +\end{description} > > \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout} > > @@ -135,15 +138,17 @@ \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 (VIRTIO_VSOCK_TYPE_STREAM) > -for stream socket types. > +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. > > \begin{lstlisting} > -#define VIRTIO_VSOCK_TYPE_STREAM 1 > +#define VIRTIO_VSOCK_TYPE_STREAM 1 > +#define VIRTIO_VSOCK_TYPE_SEQPACKET 2 > \end{lstlisting} > > Stream sockets provide in-order, guaranteed, connection-oriented delivery > -without message boundaries. > +without message boundaries. Seqpacket sockets provide in-order, guaranteed, > +connection-oriented delivery with message boundaries. > > \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 > @@ -244,6 +249,17 @@ \subsubsection{Stream Sockets}\label{sec:Device Types / Socket Device / Device O > destination) address tuple for a new connection while the other peer is still > processing the old connection. > > +\subsubsection{Seqpacket Sockets}\label{sec:Device Types / Socket Device / Device Operation / Seqpacket Sockets} > + > +\paragraph{Message boundaries}\label{sec:Device Types / Socket Device / Device Operation / Seqpacket Sockets / Message boundaries} > + > +To provide message boundaries, last RW packet of each message has VIRTIO_VSOCK_SEQ_EOR > +bit set in the \field{flags} of packet's header. > + > +\begin{lstlisting} > +#define VIRTIO_VSOCK_SEQ_EOR 1 > +\end{lstlisting} Problem is, where is device going to hold this boundary? Currently device discards the header just keeping the payload around. I suspect we need to have some kind of header per message maintained by the device and accounted for as part of the the credit accounting. > + > \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.25.1 This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2021-04-13 13:10 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-13 12:52 [virtio-comment] [RFC PATCH v5 0/2] virtio-vsock: introduce SOCK_SEQPACKET description Arseny Krasnov 2021-04-13 12:53 ` [virtio-comment] [RFC PATCH v5 1/2] virtio-vsock: use C style defines for constants Arseny Krasnov 2021-04-13 12:53 ` [virtio-comment] [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description Arseny Krasnov 2021-04-13 13:10 ` Michael S. Tsirkin [this message] 2021-04-13 13:10 ` [virtio-comment] " Michael S. Tsirkin 2021-04-13 14:22 ` Arseny Krasnov 2021-04-13 19:55 ` Michael S. Tsirkin 2021-04-13 19:55 ` [virtio-comment] " Michael S. Tsirkin 2021-04-14 6:04 ` Arseny Krasnov 2021-04-21 7:45 ` Stefano Garzarella 2021-04-21 7:45 ` [virtio-comment] " Stefano Garzarella 2021-04-21 8:24 ` Michael S. Tsirkin 2021-04-21 8:24 ` Michael S. Tsirkin 2021-04-21 9:54 ` Stefano Garzarella 2021-04-21 9:54 ` Stefano Garzarella 2021-04-21 15:09 ` Arseny Krasnov 2021-04-22 9:00 ` Stefano Garzarella 2021-04-22 9:00 ` Stefano Garzarella 2021-04-22 9:45 ` Arseny Krasnov
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=20210413090642-mutt-send-email-mst@kernel.org \ --to=mst@redhat.com \ --cc=alex.popov@linux.com \ --cc=andraprs@amazon.com \ --cc=arseny.krasnov@kaspersky.com \ --cc=cohuck@redhat.com \ --cc=colin.king@canonical.com \ --cc=davem@davemloft.net \ --cc=jeffv@google.com \ --cc=jhansen@vmware.com \ --cc=kuba@kernel.org \ --cc=nslusarek@gmx.net \ --cc=oxffffaa@gmail.com \ --cc=stefanha@redhat.com \ --cc=virtio-comment@lists.oasis-open.org \ --cc=virtualization@lists.linux-foundation.org \ /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: linkBe 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.