From: Cornelia Huck <cohuck@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Vitaly Mireyno <vmireyno@marvell.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>,
Ariel Elior <aelior@marvell.com>
Subject: [virtio-comment] Re: [PATCH v7] virtio-net: Add support for the flexible driver notification structure.
Date: Thu, 26 Mar 2020 12:52:36 +0100 [thread overview]
Message-ID: <20200326125236.4bf0c5aa.cohuck@redhat.com> (raw)
In-Reply-To: <20200326071301-mutt-send-email-mst@kernel.org>
On Thu, 26 Mar 2020 07:26:16 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Mar 26, 2020 at 10:43:20AM +0100, Cornelia Huck wrote:
> > On Wed, 18 Mar 2020 18:29:19 +0000
> > Vitaly Mireyno <vmireyno@marvell.com> wrote:
> > > +
> > > +\begin{note}
> > > +If \field{notify_off_multiplier} > 0, the virtqueue number can potentially be
> > > +derived by the device from the Queue Notify address, so \field{vqn} may be
> > > +redundant.
>
> I feel this is confusing the reader more than it explains.
> the field is always there. It's either the virtqueue number or
> whatever we get from the device.
"the virtqueue number can potentially be derived by the device from the
Queue Notify address, so obtaining the virtqueue number from
\field{vqn} is not needed"
?
>
> > > +\end{note}
> > > +
(...)
> > > @@ -4180,6 +4205,33 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
> > > See \ref{sec:Basic
> > > Facilities of a Virtio Device / Virtqueues / Message Framing}.
> > >
> > > +\subsubsection{Driver Notifications}\label{sec:Device Types / Network Device / Device Operation / Driver Notifications}
> > > +As mentioned in section \ref{sec:Virtqueues / Driver notifications}, when the
> > > +driver is required to send an available buffer notification to the device, it
> > > +always sends the virtqueue number to be notified. The method of delivering
> > > +notifications is transport specific. With the PCI transport, the device can
> > > +optionally provide a distinct per-virtqueue address for driver notifications
> > > +(Queue Notify address). In this case, the virtqueue number can potentially be
> > > +derived by the device from the Queue Notify address. For devices, that provide
> > > +per-virtqueue Queue Notify addresses and are able to derive the virtqueue number
> > > +from that address, the virtqueue number in the notification data is redundant.
> >
> > I would keep the remark that the queue number might be redundant with
> > the PCI transport.
>
> I feel redundant is too strong a word. If anything sending data we just
> read from device back to it is definitely redundant.
> Spec says send it so we send it.
> Maybe say it can be ignored by the device?
Maybe "not needed"?
(see above)
>
> > > +On the other hand, some devices can benefit from receiving additional data with
> > > +driver notifications. An example could be a hardware device implementing multiple
> > > +protocols (with virtio being one of them), so the extra notification data could
> > > +serve as a notification type indication or a protocol indication.
> >
> > Hm... what about replacing the whole text above with
> >
> > "Driver notifications (\ref{sec:Virtqueues / Driver notifications})
> > always contain at least the virtqueue number for which buffers are
> > available. Some devices can benefit from receiving additional data with
> > driver notifications. For example, a hardware device implementing
> > multiple protocols (with virtio being one of them) could benefit from a
> > notification type indication or a protocol indication."
>
>
> My problem with both versions is that it talks about
> "additional information" while in fact it's information that
> comes from the device itself.
"per-device information", maybe?
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2020-03-26 11:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 18:29 [virtio-comment] [PATCH v7] virtio-net: Add support for the flexible driver notification structure Vitaly Mireyno
2020-03-26 9:43 ` [virtio-comment] " Cornelia Huck
2020-03-26 11:26 ` Michael S. Tsirkin
2020-03-26 11:52 ` Cornelia Huck [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-03-26 12:19 Vitaly Mireyno
2020-03-30 12:59 ` [virtio-comment] " Vitaly Mireyno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200326125236.4bf0c5aa.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=aelior@marvell.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=vmireyno@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.