* [virtio-comment] [PATCH] virtio-vsock: add VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit @ 2022-07-08 13:39 Stefano Garzarella 2022-07-11 12:03 ` Cornelia Huck 0 siblings, 1 reply; 3+ messages in thread From: Stefano Garzarella @ 2022-07-08 13:39 UTC (permalink / raw) To: virtio-comment Cc: bobby.eshleman, Arseny Krasnov, Stefan Hajnoczi, Michael S . Tsirkin, jiang.wang, Stefano Garzarella Initially virtio-vsock only supported the stream type, which is why there was no feature. Later we added the seqpacket type and in the future we may have other types (e.g. datagram). seqpacket is an extension of stream, so it might be implied that if seqpacket is supported, stream is too, but this might not be true for other types. As we discussed here [1] should be better to add a new VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit to avoid this implication. Let's also add normative sections to better define the behavior when VIRTIO_VSOCK_F_NO_IMPLIED_STREAM is negotiated or not. [1] http://markmail.org/message/2s3qd74drgjxkvte Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> --- The two normative sections seem repetitive, I don't know whether it's better to have the "If ..." parts only in one section. Suggestions? --- virtio-vsock.tex | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/virtio-vsock.tex b/virtio-vsock.tex index d79984d..45f041a 100644 --- a/virtio-vsock.tex +++ b/virtio-vsock.tex @@ -16,15 +16,37 @@ \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues} \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits} -If no feature bit is set, only stream socket type is supported. -If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act -as if VIRTIO_VSOCK_F_STREAM has also been negotiated. - \begin{description} \item[VIRTIO_VSOCK_F_STREAM (0)] stream socket type is supported. \item[VIRTIO_VSOCK_F_SEQPACKET (1)] seqpacket socket type is supported. +\item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. \end{description} +\drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} + +The driver SHOULD accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature if +offered by the device. + +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature +bit, and if no feature bit has been negotiated, the driver SHOULD act as if +VIRTIO_VSOCK_F_STREAM has been negotiated. + +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the driver MAY act +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. + +\devicenormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} + +The device SHOULD offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature. + +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature +bit, and if no feature bit has been negotiated, the device SHOULD act as if +VIRTIO_VSOCK_F_STREAM has been negotiated. + +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. + \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout} Socket device configuration uses the following layout structure: -- 2.36.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/ ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-vsock: add VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit 2022-07-08 13:39 [virtio-comment] [PATCH] virtio-vsock: add VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit Stefano Garzarella @ 2022-07-11 12:03 ` Cornelia Huck 2022-07-12 9:01 ` Stefano Garzarella 0 siblings, 1 reply; 3+ messages in thread From: Cornelia Huck @ 2022-07-11 12:03 UTC (permalink / raw) To: Stefano Garzarella, virtio-comment Cc: bobby.eshleman, Arseny Krasnov, Stefan Hajnoczi, Michael S . Tsirkin, jiang.wang, Stefano Garzarella On Fri, Jul 08 2022, Stefano Garzarella <sgarzare@redhat.com> wrote: > Initially virtio-vsock only supported the stream type, which is why > there was no feature. Later we added the seqpacket type and in the future > we may have other types (e.g. datagram). > > seqpacket is an extension of stream, so it might be implied that if > seqpacket is supported, stream is too, but this might not be true for > other types. > > As we discussed here [1] should be better to add a new > VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit to avoid this implication. > > Let's also add normative sections to better define the behavior when > VIRTIO_VSOCK_F_NO_IMPLIED_STREAM is negotiated or not. > > [1] http://markmail.org/message/2s3qd74drgjxkvte > > Suggested-by: Michael S. Tsirkin <mst@redhat.com> > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> > --- > > The two normative sections seem repetitive, I don't know whether it's > better to have the "If ..." parts only in one section. > > Suggestions? > --- > virtio-vsock.tex | 30 ++++++++++++++++++++++++++---- > 1 file changed, 26 insertions(+), 4 deletions(-) > > diff --git a/virtio-vsock.tex b/virtio-vsock.tex > index d79984d..45f041a 100644 > --- a/virtio-vsock.tex > +++ b/virtio-vsock.tex > @@ -16,15 +16,37 @@ \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues} > > \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits} > > -If no feature bit is set, only stream socket type is supported. > -If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act > -as if VIRTIO_VSOCK_F_STREAM has also been negotiated. > - > \begin{description} > \item[VIRTIO_VSOCK_F_STREAM (0)] stream socket type is supported. > \item[VIRTIO_VSOCK_F_SEQPACKET (1)] seqpacket socket type is supported. > +\item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. > \end{description} > > +\drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > + > +The driver SHOULD accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature if > +offered by the device. > + > +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature > +bit, and if no feature bit has been negotiated, the driver SHOULD act as if > +VIRTIO_VSOCK_F_STREAM has been negotiated. > + > +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature > +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the driver MAY act > +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. These statements talk about what happens if the device did not offer NO_IMPLIED_STREAM in the first place; we instruct that the driver SHOULD accept the flag, but do we still need to define what is supposed to happen if the driver does not, after all, accept NO_IMPLIED_STREAM? That would make the statements "If no feature bit has been negotiated, ..." and "If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, but not VIRTIO_VSOCK_F_NO_IMPLIED_STREAM, ...", which is also a bit shorter (and less repetivive :) > + > +\devicenormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} > + > +The device SHOULD offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature. > + > +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature > +bit, and if no feature bit has been negotiated, the device SHOULD act as if > +VIRTIO_VSOCK_F_STREAM has been negotiated. Maybe make this "If no feature bit has been negotiated, ..." (similar reasoning as above)? > + > +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature > +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act > +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. And maybe "If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, but not VIRTIO_VSOCK_F_NO_IMPLIED_STREAM, ..." here as well. > + > \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout} > > Socket device configuration uses the following layout structure: In any case, the new conformance sections need to be hooked up in conformance.tex. 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/ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [virtio-comment] [PATCH] virtio-vsock: add VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit 2022-07-11 12:03 ` Cornelia Huck @ 2022-07-12 9:01 ` Stefano Garzarella 0 siblings, 0 replies; 3+ messages in thread From: Stefano Garzarella @ 2022-07-12 9:01 UTC (permalink / raw) To: Cornelia Huck Cc: virtio-comment, bobby.eshleman, Arseny Krasnov, Stefan Hajnoczi, Michael S . Tsirkin, jiang.wang On Mon, Jul 11, 2022 at 02:03:03PM +0200, Cornelia Huck wrote: >On Fri, Jul 08 2022, Stefano Garzarella <sgarzare@redhat.com> wrote: > >> Initially virtio-vsock only supported the stream type, which is why >> there was no feature. Later we added the seqpacket type and in the future >> we may have other types (e.g. datagram). >> >> seqpacket is an extension of stream, so it might be implied that if >> seqpacket is supported, stream is too, but this might not be true for >> other types. >> >> As we discussed here [1] should be better to add a new >> VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit to avoid this implication. >> >> Let's also add normative sections to better define the behavior when >> VIRTIO_VSOCK_F_NO_IMPLIED_STREAM is negotiated or not. >> >> [1] http://markmail.org/message/2s3qd74drgjxkvte >> >> Suggested-by: Michael S. Tsirkin <mst@redhat.com> >> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> >> --- >> >> The two normative sections seem repetitive, I don't know whether it's >> better to have the "If ..." parts only in one section. >> >> Suggestions? >> --- >> virtio-vsock.tex | 30 ++++++++++++++++++++++++++---- >> 1 file changed, 26 insertions(+), 4 deletions(-) >> >> diff --git a/virtio-vsock.tex b/virtio-vsock.tex >> index d79984d..45f041a 100644 >> --- a/virtio-vsock.tex >> +++ b/virtio-vsock.tex >> @@ -16,15 +16,37 @@ \subsection{Virtqueues}\label{sec:Device Types / Socket Device / Virtqueues} >> >> \subsection{Feature bits}\label{sec:Device Types / Socket Device / Feature bits} >> >> -If no feature bit is set, only stream socket type is supported. >> -If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act >> -as if VIRTIO_VSOCK_F_STREAM has also been negotiated. >> - >> \begin{description} >> \item[VIRTIO_VSOCK_F_STREAM (0)] stream socket type is supported. >> \item[VIRTIO_VSOCK_F_SEQPACKET (1)] seqpacket socket type is supported. >> +\item[VIRTIO_VSOCK_F_NO_IMPLIED_STREAM (2)] stream socket type is not implied. >> \end{description} >> >> +\drivernormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} >> + >> +The driver SHOULD accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature if >> +offered by the device. >> + >> +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature >> +bit, and if no feature bit has been negotiated, the driver SHOULD act as if >> +VIRTIO_VSOCK_F_STREAM has been negotiated. >> + >> +If the device does not offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature >> +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the driver MAY act >> +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. > >These statements talk about what happens if the device did not offer >NO_IMPLIED_STREAM in the first place; we instruct that the driver SHOULD >accept the flag, but do we still need to define what is supposed to >happen if the driver does not, after all, accept NO_IMPLIED_STREAM? > >That would make the statements "If no feature bit has been negotiated, >..." and "If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, but not >VIRTIO_VSOCK_F_NO_IMPLIED_STREAM, ...", which is also a bit shorter (and >less repetivive :) Yep, much better! > >> + >> +\devicenormative{\subsubsection}{Feature bits}{Device Types / Socket Device / Feature bits} >> + >> +The device SHOULD offer the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature. >> + >> +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature >> +bit, and if no feature bit has been negotiated, the device SHOULD act as if >> +VIRTIO_VSOCK_F_STREAM has been negotiated. > >Maybe make this "If no feature bit has been negotiated, ..." (similar >reasoning as above)? Agree. > >> + >> +If the driver does not accept the VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature >> +bit, and if VIRTIO_VSOCK_F_SEQPACKET has been negotiated, the device MAY act >> +as if VIRTIO_VSOCK_F_STREAM has also been negotiated. > >And maybe "If VIRTIO_VSOCK_F_SEQPACKET has been negotiated, but not >VIRTIO_VSOCK_F_NO_IMPLIED_STREAM, ..." here as well. Yep. > >> + >> \subsection{Device configuration layout}\label{sec:Device Types / Socket Device / Device configuration layout} >> >> Socket device configuration uses the following layout structure: > >In any case, the new conformance sections need to be hooked up in >conformance.tex. > Ooops, I'll do in the next version! Thanks for the review, Stefano ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-07-12 9:01 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-08 13:39 [virtio-comment] [PATCH] virtio-vsock: add VIRTIO_VSOCK_F_NO_IMPLIED_STREAM feature bit Stefano Garzarella 2022-07-11 12:03 ` Cornelia Huck 2022-07-12 9:01 ` Stefano Garzarella
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.