All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Ganrot <lga@napatech.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	"virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>
Subject: RE: [virtio-dev] [PATCH RFC] packed ring layout spec v5
Date: Sat, 25 Nov 2017 19:55:53 +0000	[thread overview]
Message-ID: <24fcb5e29d8d446fa6a13d262205edc4@napatech.com> (raw)
In-Reply-To: <20171108141659-mutt-send-email-mst@kernel.org>

Hi Michael and others,

Hopefully my question below follows the forum format.

BR,

-Lars
> 
> \subsection{In-order use of descriptors} \label{sec:Packed Virtqueues / In-order
> use of descriptors}
> 
> Some devices always use descriptors in the same order in which they have been
> made available. These devices can offer the VIRTIO_F_IN_ORDER feature. If
> negotiated, this knowledge allows devices to notify the use of a batch of buffers
> to the driver by only writing out a single used descriptor with the Buffer ID
> corresponding to the last descriptor in the batch.
>  
This VIRTIO_F_IN_ORDER feature bit answers one of my earlier questions, however I'm curious if it couldn't also be usable in the non-ring Virtqueue?

If the device always returns buffers in order, then couldn't the driver skip the step of reading the used.ring for read-only buffers  (e.g. TX for net devices)? The used.idx tells how many buffers were returned, and since they are returned in the same order as the driver sent them, it knows what their indices are. This would then save one cache-miss in the old structure too.

And a follow-up questions would then be: if a device always returns buffers in order, does the v1.0 specification not require drivers to reuse descriptors in the same order as they are returned? I think 3.2.1.1 implies that at least. If so, wouldn't new descriptors always be placed back2back in the descriptor table (contiguous memory)?

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  parent reply	other threads:[~2017-11-25 19:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 12:28 [virtio-dev] [PATCH RFC] packed ring layout spec v4 Michael S. Tsirkin
2017-11-08 12:30 ` [virtio-dev] " Michael S. Tsirkin
2017-11-10 15:08   ` Dhanoa, Kully
2017-11-10 15:39     ` Stefan Hajnoczi
2017-11-22 14:57     ` Michael S. Tsirkin
2017-11-10 11:40 ` [virtio-dev] " Stefan Hajnoczi
2017-11-16 10:44 ` Lars Ganrot
2017-11-24 10:00 ` [virtio-dev] [PATCH RFC] packed ring layout spec v5 Dhanoa, Kully
2017-11-24 16:28   ` Michael S. Tsirkin
2017-11-28  3:26   ` Michael S. Tsirkin
2017-11-25 19:55 ` Lars Ganrot [this message]
2017-11-28 14:36   ` Michael S. Tsirkin
2017-11-29  8:12     ` Lars Ganrot

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=24fcb5e29d8d446fa6a13d262205edc4@napatech.com \
    --to=lga@napatech.com \
    --cc=mst@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: 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.