[virtio-comment] [RFC PATCH v5 0/2] virtio-vsock: introduce SOCK_SEQPACKET description

[virtio-comment] [RFC PATCH v5 0/2] virtio-vsock: introduce SOCK_SEQPACKET description

[Arseny Krasnov]

This adds description of SOCK_SEQPACKET type for virtio-vsock.

Here is latest RFC implementation for Linux, with more details:

https://lkml.org/lkml/2021/4/13/579

Also this patchset has patch which replaces enums to defines in
virtio-vsock part of spec. SOCK_SEQPACKET patch is based on it.

 Arseny Krasnov(2):
  virtio-vsock: use C style defines for constants
  virtio-vsock: SOCK_SEQPACKET description

 virtio-vsock.tex | 65 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 59 insertions(+), 6 deletions(-)
---
 dummy.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 dummy.txt

diff --git a/dummy.txt b/dummy.txt
new file mode 100644
index 0000000..e69de29
-- 
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/

[virtio-comment] [RFC PATCH v5 1/2] virtio-vsock: use C style defines for constants

[Arseny Krasnov]

This:
1) Replaces enums with C style "defines", because
   use of enums is not documented, while "defines"
   are widely used in spec.
2) Adds defines for some constants.

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
---
 virtio-vsock.tex | 54 +++++++++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/virtio-vsock.tex b/virtio-vsock.tex
index da7e641..ad57f9d 100644
--- a/virtio-vsock.tex
+++ b/virtio-vsock.tex
@@ -86,23 +86,18 @@ \subsection{Device Operation}\label{sec:Device Types / Socket Device / Device Op
 operation constants:
 
 \begin{lstlisting}
-enum {
-	VIRTIO_VSOCK_OP_INVALID = 0,
-
-	/* Connect operations */
-	VIRTIO_VSOCK_OP_REQUEST = 1,
-	VIRTIO_VSOCK_OP_RESPONSE = 2,
-	VIRTIO_VSOCK_OP_RST = 3,
-	VIRTIO_VSOCK_OP_SHUTDOWN = 4,
-
-	/* To send payload */
-	VIRTIO_VSOCK_OP_RW = 5,
-
-	/* Tell the peer our credit info */
-	VIRTIO_VSOCK_OP_CREDIT_UPDATE = 6,
-	/* Request the peer to send the credit info to us */
-	VIRTIO_VSOCK_OP_CREDIT_REQUEST = 7,
-};
+#define VIRTIO_VSOCK_OP_INVALID        0
+/* Connect operations */
+#define VIRTIO_VSOCK_OP_REQUEST        1
+#define VIRTIO_VSOCK_OP_RESPONSE       2
+#define VIRTIO_VSOCK_OP_RST            3
+#define VIRTIO_VSOCK_OP_SHUTDOWN       4
+/* To send payload */
+#define VIRTIO_VSOCK_OP_RW             5
+/* Tell the peer our credit info */
+#define VIRTIO_VSOCK_OP_CREDIT_UPDATE  6
+/* Request the peer to send the credit info to us */
+#define VIRTIO_VSOCK_OP_CREDIT_REQUEST 7
 \end{lstlisting}
 
 \subsubsection{Virtqueue Flow Control}\label{sec:Device Types / Socket Device / Device Operation / Virtqueue Flow Control}
@@ -140,8 +135,12 @@ \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 only stream sockets are supported. \field{type} is 1 (VIRTIO_VSOCK_TYPE_STREAM)
+for stream socket types.
+
+\begin{lstlisting}
+#define VIRTIO_VSOCK_TYPE_STREAM 1
+\end{lstlisting}
 
 Stream sockets provide in-order, guaranteed, connection-oriented delivery
 without message boundaries.
@@ -222,10 +221,15 @@ \subsubsection{Stream Sockets}\label{sec:Device Types / Socket Device / Device O
 insufficient resources to establish the connection.
 
 When a connected socket receives VIRTIO_VSOCK_OP_SHUTDOWN the header
-\field{flags} field bit 0 indicates that the peer will not receive any more
-data and bit 1 indicates that the peer will not send any more data.  These
-hints are permanent once sent and successive packets with bits clear do not
-reset them.
+\field{flags} field bit VIRTIO_VSOCK_SHUTDOWN_F_RECEIVE (bit 0) set indicates
+that the peer will not receive any more data and bit VIRTIO_VSOCK_SHUTDOWN_F_SEND
+(bit 1) set indicates that the peer will not send any more data.  These hints are
+permanent once sent and successive packets with bits clear do not reset them.
+
+\begin{lstlisting}
+#define VIRTIO_VSOCK_SHUTDOWN_F_RECEIVE 0
+#define VIRTIO_VSOCK_SHUTDOWN_F_SEND    1
+\end{lstlisting}
 
 The VIRTIO_VSOCK_OP_RST packet aborts the connection process or forcibly
 disconnects a connected socket.
@@ -248,9 +252,7 @@ \subsubsection{Device Events}\label{sec:Device Types / Socket Device / Device Op
 The event buffer is as follows:
 
 \begin{lstlisting}
-enum virtio_vsock_event_id {
-        VIRTIO_VSOCK_EVENT_TRANSPORT_RESET = 0,
-};
+#define VIRTIO_VSOCK_EVENT_TRANSPORT_RESET 0
 
 struct virtio_vsock_event {
         le32 id;
-- 
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/

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

[Arseny Krasnov]

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.
+\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}
+
 \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/

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

[Michael S. Tsirkin]

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

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

[Michael S. Tsirkin]

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/

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

[Arseny Krasnov]

On 13.04.2021 16:10, Michael S. Tsirkin wrote:
> 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 ...

You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types

are supported"?

>
>> +\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.

IIUC, in Linux, header's are copied by vhost between buffer

in virtqueue and buffer in virtio vsock driver(host to guest transmission and

guest to host transmission). E.g. values of header's field are visible by driver.

>
>
>> +
>>  \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/

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

[Michael S. Tsirkin]

On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
> 
> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
> > 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 ...
> 
> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
> 
> are supported"?


No. I am asking whether we want a feature bit for SOCK_STREAM too?


> >
> >> +\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.
> 
> IIUC, in Linux, header's are copied by vhost between buffer
> 
> in virtqueue and buffer in virtio vsock driver(host to guest transmission and
> 
> guest to host transmission). E.g. values of header's field are visible by driver.

The question is about credit accounting.  With stream we can add as
little as a single byte with no overhead. No so with seqpacket each
boundary adds memory overhead.  This memory needs to be accounted for.
How much I'm not sure. Maybe it needs to be negotiated during
connection?



> >
> >
> >> +
> >>  \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

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

[Michael S. Tsirkin]

On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
> 
> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
> > 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 ...
> 
> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
> 
> are supported"?


No. I am asking whether we want a feature bit for SOCK_STREAM too?


> >
> >> +\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.
> 
> IIUC, in Linux, header's are copied by vhost between buffer
> 
> in virtqueue and buffer in virtio vsock driver(host to guest transmission and
> 
> guest to host transmission). E.g. values of header's field are visible by driver.

The question is about credit accounting.  With stream we can add as
little as a single byte with no overhead. No so with seqpacket each
boundary adds memory overhead.  This memory needs to be accounted for.
How much I'm not sure. Maybe it needs to be negotiated during
connection?



> >
> >
> >> +
> >>  \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/

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

[Arseny Krasnov]

On 13.04.2021 22:55, Michael S. Tsirkin wrote:
> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>> 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 ...
>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>
>> are supported"?
>
> No. I am asking whether we want a feature bit for SOCK_STREAM too?

I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET

is stream + message boundaries and potential DGRAM is completely different

thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only

esthetic in this: all three socket types have own feature bits.

>
>
>>>> +\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.
>> IIUC, in Linux, header's are copied by vhost between buffer
>>
>> in virtqueue and buffer in virtio vsock driver(host to guest transmission and
>>
>> guest to host transmission). E.g. values of header's field are visible by driver.
> The question is about credit accounting.  With stream we can add as
> little as a single byte with no overhead. No so with seqpacket each
> boundary adds memory overhead.  This memory needs to be accounted for.
> How much I'm not sure. Maybe it needs to be negotiated during
> connection?

Sorry, i don't understand. boundary is bit in flags of RW packet. These RW

packets are inserted to rx queue of socket, in the same way as for stream

socket. The only difference is that user is not woken up until boundary found.

All credit account logic works same in both stream and seqpacket.

>
>
>
>>>
>>>> +
>>>>  \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/

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

[Stefano Garzarella]

On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>
>On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>> 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 ...
>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>
>>> are supported"?
>>
>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>
>I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>
>is stream + message boundaries and potential DGRAM is completely different
>
>thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>
>esthetic in this: all three socket types have own feature bits.
>

I agree that it may make sense to have a bit for SOCK_STREAM. For 
example we may have devices in the future that want to implement only 
DGRAM for simplicity.

I'm just worried about backwards compatibility with current devices 
where we don't have any feature bit.

Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
I don't like it much, but I can't think of anything better.

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

[Stefano Garzarella]

On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>
>On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>> 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 ...
>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>
>>> are supported"?
>>
>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>
>I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>
>is stream + message boundaries and potential DGRAM is completely different
>
>thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>
>esthetic in this: all three socket types have own feature bits.
>

I agree that it may make sense to have a bit for SOCK_STREAM. For 
example we may have devices in the future that want to implement only 
DGRAM for simplicity.

I'm just worried about backwards compatibility with current devices 
where we don't have any feature bit.

Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
I don't like it much, but I can't think of anything better.

Thanks,
Stefano


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/

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

[Michael S. Tsirkin]

On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
> > 
> > On 13.04.2021 22:55, Michael S. Tsirkin wrote:
> > > On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
> > > > On 13.04.2021 16:10, Michael S. Tsirkin wrote:
> > > > > 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 ...
> > > > You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
> > > > 
> > > > are supported"?
> > > 
> > > No. I am asking whether we want a feature bit for SOCK_STREAM too?
> > 
> > I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
> > 
> > is stream + message boundaries and potential DGRAM is completely different
> > 
> > thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
> > 
> > esthetic in this: all three socket types have own feature bits.
> > 
> 
> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
> may have devices in the future that want to implement only DGRAM for
> simplicity.
> 
> I'm just worried about backwards compatibility with current devices where we
> don't have any feature bit.
> 
> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
> I don't like it much, but I can't think of anything better.
> 
> Thanks,
> Stefano

We can simply specify that if there are no feature bits at all then
stream is assumed supported.


> 
> 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/

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

[Michael S. Tsirkin]

On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
> > 
> > On 13.04.2021 22:55, Michael S. Tsirkin wrote:
> > > On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
> > > > On 13.04.2021 16:10, Michael S. Tsirkin wrote:
> > > > > 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 ...
> > > > You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
> > > > 
> > > > are supported"?
> > > 
> > > No. I am asking whether we want a feature bit for SOCK_STREAM too?
> > 
> > I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
> > 
> > is stream + message boundaries and potential DGRAM is completely different
> > 
> > thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
> > 
> > esthetic in this: all three socket types have own feature bits.
> > 
> 
> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
> may have devices in the future that want to implement only DGRAM for
> simplicity.
> 
> I'm just worried about backwards compatibility with current devices where we
> don't have any feature bit.
> 
> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
> I don't like it much, but I can't think of anything better.
> 
> Thanks,
> Stefano

We can simply specify that if there are no feature bits at all then
stream is assumed supported.


> 
> 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/


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/

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

[Stefano Garzarella]

On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>> >
>> > On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>> > > On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>> > > > On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>> > > > > 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 ...
>> > > > You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>> > > >
>> > > > are supported"?
>> > >
>> > > No. I am asking whether we want a feature bit for SOCK_STREAM too?
>> >
>> > I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>> >
>> > is stream + message boundaries and potential DGRAM is completely different
>> >
>> > thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>> >
>> > esthetic in this: all three socket types have own feature bits.
>> >
>>
>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>> may have devices in the future that want to implement only DGRAM for
>> simplicity.
>>
>> I'm just worried about backwards compatibility with current devices where we
>> don't have any feature bit.
>>
>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>> I don't like it much, but I can't think of anything better.
>>
>> Thanks,
>> Stefano
>
>We can simply specify that if there are no feature bits at all then
>stream is assumed supported.
>

oh yeah, that sounds like a good idea!

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

[Stefano Garzarella]

On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>> >
>> > On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>> > > On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>> > > > On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>> > > > > 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 ...
>> > > > You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>> > > >
>> > > > are supported"?
>> > >
>> > > No. I am asking whether we want a feature bit for SOCK_STREAM too?
>> >
>> > I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>> >
>> > is stream + message boundaries and potential DGRAM is completely different
>> >
>> > thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>> >
>> > esthetic in this: all three socket types have own feature bits.
>> >
>>
>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>> may have devices in the future that want to implement only DGRAM for
>> simplicity.
>>
>> I'm just worried about backwards compatibility with current devices where we
>> don't have any feature bit.
>>
>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>> I don't like it much, but I can't think of anything better.
>>
>> Thanks,
>> Stefano
>
>We can simply specify that if there are no feature bits at all then
>stream is assumed supported.
>

oh yeah, that sounds like a good idea!

Thanks,
Stefano


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/

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

[Arseny Krasnov]

On 21.04.2021 12:54, Stefano Garzarella wrote:
> On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>> On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>>>> On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>>>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>>>>> 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 ...
>>>>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>>>>
>>>>>> are supported"?
>>>>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>>>> I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>>>>
>>>> is stream + message boundaries and potential DGRAM is completely different
>>>>
>>>> thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>>>>
>>>> esthetic in this: all three socket types have own feature bits.
>>>>
>>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>>> may have devices in the future that want to implement only DGRAM for
>>> simplicity.
>>>
>>> I'm just worried about backwards compatibility with current devices where we
>>> don't have any feature bit.
>>>
>>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>>> I don't like it much, but I can't think of anything better.
>>>
>>> Thanks,
>>> Stefano
>> We can simply specify that if there are no feature bits at all then
>> stream is assumed supported.
>>
> oh yeah, that sounds like a good idea!

So it is not necessary for my SEQPACKET patchset to support STREAM in both

kernel and spec?


Thank, Arseny

> Thanks,
> Stefano
>
>
> 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/
>
>

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/

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

[Stefano Garzarella]

On Wed, Apr 21, 2021 at 06:09:21PM +0300, Arseny Krasnov wrote:
>
>On 21.04.2021 12:54, Stefano Garzarella wrote:
>> On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>>> On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>>>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>>>>> On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>>>>>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>>>>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>>>>>> 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 ...
>>>>>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>>>>>
>>>>>>> are supported"?
>>>>>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>>>>> I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>>>>>
>>>>> is stream + message boundaries and potential DGRAM is completely different
>>>>>
>>>>> thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>>>>>
>>>>> esthetic in this: all three socket types have own feature bits.
>>>>>
>>>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>>>> may have devices in the future that want to implement only DGRAM for
>>>> simplicity.
>>>>
>>>> I'm just worried about backwards compatibility with current devices where we
>>>> don't have any feature bit.
>>>>
>>>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>>>> I don't like it much, but I can't think of anything better.
>>>>
>>>> Thanks,
>>>> Stefano
>>> We can simply specify that if there are no feature bits at all then
>>> stream is assumed supported.
>>>
>> oh yeah, that sounds like a good idea!
>
>So it is not necessary for my SEQPACKET patchset to support STREAM in both
>kernel and spec?
>

I don't think it's necessary for SEQPACKET, but I would reserve bit 0 to 
stream.

We could add a patch to this series that adds the bit for stream and 
explains that if there is no feature bit set, then only stream is 
supported.

Or I can send it separately if you don't want to include it in the 
series.

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

[Stefano Garzarella]

On Wed, Apr 21, 2021 at 06:09:21PM +0300, Arseny Krasnov wrote:
>
>On 21.04.2021 12:54, Stefano Garzarella wrote:
>> On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>>> On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>>>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>>>>> On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>>>>>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>>>>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>>>>>> 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 ...
>>>>>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>>>>>
>>>>>>> are supported"?
>>>>>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>>>>> I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>>>>>
>>>>> is stream + message boundaries and potential DGRAM is completely different
>>>>>
>>>>> thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>>>>>
>>>>> esthetic in this: all three socket types have own feature bits.
>>>>>
>>>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>>>> may have devices in the future that want to implement only DGRAM for
>>>> simplicity.
>>>>
>>>> I'm just worried about backwards compatibility with current devices where we
>>>> don't have any feature bit.
>>>>
>>>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>>>> I don't like it much, but I can't think of anything better.
>>>>
>>>> Thanks,
>>>> Stefano
>>> We can simply specify that if there are no feature bits at all then
>>> stream is assumed supported.
>>>
>> oh yeah, that sounds like a good idea!
>
>So it is not necessary for my SEQPACKET patchset to support STREAM in both
>kernel and spec?
>

I don't think it's necessary for SEQPACKET, but I would reserve bit 0 to 
stream.

We could add a patch to this series that adds the bit for stream and 
explains that if there is no feature bit set, then only stream is 
supported.

Or I can send it separately if you don't want to include it in the 
series.

Thanks,
Stefano


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/

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

[Arseny Krasnov]

On 22.04.2021 12:00, Stefano Garzarella wrote:
> On Wed, Apr 21, 2021 at 06:09:21PM +0300, Arseny Krasnov wrote:
>> On 21.04.2021 12:54, Stefano Garzarella wrote:
>>> On Wed, Apr 21, 2021 at 04:24:36AM -0400, Michael S. Tsirkin wrote:
>>>> On Wed, Apr 21, 2021 at 09:45:23AM +0200, Stefano Garzarella wrote:
>>>>> On Wed, Apr 14, 2021 at 09:04:47AM +0300, Arseny Krasnov wrote:
>>>>>> On 13.04.2021 22:55, Michael S. Tsirkin wrote:
>>>>>>> On Tue, Apr 13, 2021 at 05:22:44PM +0300, Arseny Krasnov wrote:
>>>>>>>> On 13.04.2021 16:10, Michael S. Tsirkin wrote:
>>>>>>>>> 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 ...
>>>>>>>> You mean, this sentence must be "Both SOCK_SEQPACKET and SOCK_STREAM types
>>>>>>>>
>>>>>>>> are supported"?
>>>>>>> No. I am asking whether we want a feature bit for SOCK_STREAM too?
>>>>>> I think  there is no practical sense in SOCK_STREAM bit, because SOCK_SEQPACKET
>>>>>>
>>>>>> is stream + message boundaries and potential DGRAM is completely different
>>>>>>
>>>>>> thing. Of course i can implement it in my patches and also add it to spec patch, but  i see only
>>>>>>
>>>>>> esthetic in this: all three socket types have own feature bits.
>>>>>>
>>>>> I agree that it may make sense to have a bit for SOCK_STREAM. For example we
>>>>> may have devices in the future that want to implement only DGRAM for
>>>>> simplicity.
>>>>>
>>>>> I'm just worried about backwards compatibility with current devices where we
>>>>> don't have any feature bit.
>>>>>
>>>>> Should we add a negative feature flag? (e.g. VIRTIO_VSOCK_F_NO_STREAM)
>>>>> I don't like it much, but I can't think of anything better.
>>>>>
>>>>> Thanks,
>>>>> Stefano
>>>> We can simply specify that if there are no feature bits at all then
>>>> stream is assumed supported.
>>>>
>>> oh yeah, that sounds like a good idea!
>> So it is not necessary for my SEQPACKET patchset to support STREAM in both
>> kernel and spec?
>>
> I don't think it's necessary for SEQPACKET, but I would reserve bit 0 to 
> stream.
>
> We could add a patch to this series that adds the bit for stream and 
> explains that if there is no feature bit set, then only stream is 
> supported.
>
> Or I can send it separately if you don't want to include it in the 
> series.

I can use bit 1 for SEQPACKET, keeping bit 0 free for STREAM, but

i'd like to exclude this from patchset, to make it smaller

>
> Thanks,
> Stefano
>
>

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/