* Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description [not found] ` <20210413125333.3419315-1-arseny.krasnov@kaspersky.com> @ 2021-04-13 13:10 ` Michael S. Tsirkin [not found] ` <92a6b268-a36a-5f1b-2d67-02accfde70ce@kaspersky.com> 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2021-04-13 13:10 UTC (permalink / raw) To: Arseny Krasnov Cc: Andra Paraschiv, Jeff Vander Stoep, cohuck, Colin Ian King, oxffffaa, Norbert Slusarek, Stefan Hajnoczi, virtio-comment, Jakub Kicinski, Alexander Popov, virtualization, David S. Miller, Jorgen Hansen 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <92a6b268-a36a-5f1b-2d67-02accfde70ce@kaspersky.com>]
* Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description [not found] ` <92a6b268-a36a-5f1b-2d67-02accfde70ce@kaspersky.com> @ 2021-04-13 19:55 ` Michael S. Tsirkin [not found] ` <783d12e5-50b6-2363-f953-bc95d4b59d72@kaspersky.com> 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2021-04-13 19:55 UTC (permalink / raw) To: Arseny Krasnov Cc: Andra Paraschiv, Jeff Vander Stoep, cohuck@redhat.com, Colin Ian King, oxffffaa@gmail.com, Norbert Slusarek, Stefan Hajnoczi, virtio-comment@lists.oasis-open.org, Jakub Kicinski, Alexander Popov, virtualization@lists.linux-foundation.org, David S. Miller, Jorgen Hansen 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <783d12e5-50b6-2363-f953-bc95d4b59d72@kaspersky.com>]
* Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description [not found] ` <783d12e5-50b6-2363-f953-bc95d4b59d72@kaspersky.com> @ 2021-04-21 7:45 ` Stefano Garzarella 2021-04-21 8:24 ` [virtio-comment] " Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Stefano Garzarella @ 2021-04-21 7:45 UTC (permalink / raw) To: Arseny Krasnov, Michael S. Tsirkin Cc: Andra Paraschiv, Jeff Vander Stoep, cohuck@redhat.com, Colin Ian King, oxffffaa@gmail.com, Norbert Slusarek, Stefan Hajnoczi, virtio-comment@lists.oasis-open.org, Jakub Kicinski, virtualization@lists.linux-foundation.org, David S. Miller, Jorgen Hansen, Alexander Popov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description 2021-04-21 7:45 ` Stefano Garzarella @ 2021-04-21 8:24 ` Michael S. Tsirkin 2021-04-21 9:54 ` Stefano Garzarella 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2021-04-21 8:24 UTC (permalink / raw) To: Stefano Garzarella Cc: Andra Paraschiv, Jeff Vander Stoep, cohuck@redhat.com, Colin Ian King, oxffffaa@gmail.com, Norbert Slusarek, Stefan Hajnoczi, virtio-comment@lists.oasis-open.org, Jakub Kicinski, Arseny Krasnov, virtualization@lists.linux-foundation.org, David S. Miller, Jorgen Hansen, Alexander Popov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio-comment] Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description 2021-04-21 8:24 ` [virtio-comment] " Michael S. Tsirkin @ 2021-04-21 9:54 ` Stefano Garzarella [not found] ` <acd87b8c-f030-f757-130e-edab0e460cce@kaspersky.com> 0 siblings, 1 reply; 6+ messages in thread From: Stefano Garzarella @ 2021-04-21 9:54 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andra Paraschiv, Jeff Vander Stoep, cohuck@redhat.com, Colin Ian King, oxffffaa@gmail.com, Norbert Slusarek, Stefan Hajnoczi, virtio-comment@lists.oasis-open.org, Jakub Kicinski, Arseny Krasnov, virtualization@lists.linux-foundation.org, David S. Miller, Jorgen Hansen, Alexander Popov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <acd87b8c-f030-f757-130e-edab0e460cce@kaspersky.com>]
* Re: [virtio-comment] Re: [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description [not found] ` <acd87b8c-f030-f757-130e-edab0e460cce@kaspersky.com> @ 2021-04-22 9:00 ` Stefano Garzarella 0 siblings, 0 replies; 6+ messages in thread From: Stefano Garzarella @ 2021-04-22 9:00 UTC (permalink / raw) To: Arseny Krasnov Cc: Andra Paraschiv, Michael S. Tsirkin, Jeff Vander Stoep, cohuck@redhat.com, Colin Ian King, oxffffaa@gmail.com, Norbert Slusarek, Stefan Hajnoczi, virtio-comment@lists.oasis-open.org, Jakub Kicinski, virtualization@lists.linux-foundation.org, David S. Miller, Jorgen Hansen, Alexander Popov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-22 9:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210413125217.3416876-1-arseny.krasnov@kaspersky.com>
[not found] ` <20210413125333.3419315-1-arseny.krasnov@kaspersky.com>
2021-04-13 13:10 ` [RFC PATCH v5 2/2] virtio-vsock: SOCK_SEQPACKET description Michael S. Tsirkin
[not found] ` <92a6b268-a36a-5f1b-2d67-02accfde70ce@kaspersky.com>
2021-04-13 19:55 ` Michael S. Tsirkin
[not found] ` <783d12e5-50b6-2363-f953-bc95d4b59d72@kaspersky.com>
2021-04-21 7:45 ` Stefano Garzarella
2021-04-21 8:24 ` [virtio-comment] " Michael S. Tsirkin
2021-04-21 9:54 ` Stefano Garzarella
[not found] ` <acd87b8c-f030-f757-130e-edab0e460cce@kaspersky.com>
2021-04-22 9:00 ` Stefano Garzarella
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).