All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: David Riddoch <driddoch@solarflare.com>,
	Virtio-Dev <virtio-dev@lists.oasis-open.org>
Subject: Re: [virtio-dev] RFC: Doorbell suppression, packed-ring mode and hardware offload
Date: Wed, 13 Feb 2019 12:30:06 -0500	[thread overview]
Message-ID: <20190213121733-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f120aec1-60d7-33e2-9188-4abbdd887532@redhat.com>

On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
> 
> On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
> > On Tue, Feb 12, 2019 at 04:47:08PM +0000, David Riddoch wrote:
> > > > > > > I would prefer to have the write barrier before writing the idx.
> > > > > > Well that's driver overhead for something device might never utilise in
> > > > > > a given workload. If we are optimizing let's optimize for speed.
> > > > > I think doing the barrier before writing idx is best for speed (see below).
> > > > I don't see it below:(
> > > Sorry, I'm not being clear.  If the write barrier is before the idx, then a
> > > PV device can read the idx, do a single rmb and read a whole bunch of
> > > descriptors.  As things stand today a PV device has to do an rmb for each
> > > descriptor that it reads.
> > > 
> > > I'm not sure, but this may be what Jason meant when he said "prefetch".
> 
> 
> Yes.
> 
> 
> > Oh. Right. So for PV it's easy to convert an rmb to a data dependency
> > instead.  It remains to be seen whether an extra cache miss per
> > batch is cheaper or more expensive than such a dependency
> > per descriptor.
> > 
> > I hope Jason can experiment and let us know.
> > 
> > 
> 
> To clarify, actually I did play someting like:
> 
> 
> if (desc_is_avail((last_avail + 32) % size))
> 
>     [last_avail, last_avail + 32] is avail [1]
> 
> else if (desc_is_avail(last_avail + 1) % size))
> 
>     last_avail is avail
> 
> else
> 
>    no new
> 
> 
> And looks like [1] depends on the driver to do:
> 
> for all descriptors
> 
>     update desc (but not make it available for the flag)
> 
> wmb()
> 
> for all descriptors
> 
>     update desc.flag
> 
> 
> This means if last_avail + 32 is avail, no need to check flags of
> [last_avail, last_avail + 31] since the descriptor content (except for the
> flag) is guaranteed to be correct.

We can try looking into that, sure. It's not just wmb though which is
anyway free on x86. There are cases of e.g. chained descriptors
to consider where we do not want device to see a partial chain.


> I get ~10% PPS improvement.
> 
> Thanks

I suspect most of the gain isn't in the check at all though.
It's probably reading descriptors and maybe loop unrolling.
Something like:

__attribute__((optimize("unroll-loops")))
bool fast_get_descriptors(vq, desc)
{

	copy X descriptors
	u16 aflags = 0xffff;
	u16 oflags = 0x0;
	for (i = 0; i < X; ++i) {
		aflags &= desc[i].flags;
		oflags |= desc[i].flags;
	}
	/* all flags must be same */
	if (aflags != oflags)
		return false;

	return is_avail(vq->wrapcount, aflags);
}


I also think 32 is very aggressive, I would start with 8.


With above, you could try:

	if (fast_get_descriptors(vq, desc))
	     [last_avail, last_avail + 32] is avail [1]
 
	else if (desc_is_avail(last_avail + 1) % size))
	     last_avail is avail
 
	 else
 	 	no new


-- 
MST

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


  reply	other threads:[~2019-02-13 17:30 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01 14:23 [virtio-dev] RFC: Doorbell suppression, packed-ring mode and hardware offload David Riddoch
2019-02-11  7:33 ` Michael S. Tsirkin
2019-02-11  8:52   ` David Riddoch
2019-02-11 14:24     ` Michael S. Tsirkin
2019-02-11 14:58       ` David Riddoch
2019-02-12  5:08         ` Michael S. Tsirkin
2019-02-12  7:28           ` Jason Wang
2019-02-12 13:44             ` Michael S. Tsirkin
2019-02-13 10:00               ` Jason Wang
2019-02-13 15:20                 ` Michael S. Tsirkin
2019-02-14  3:21                   ` Jason Wang
2019-02-14  3:41                     ` Michael S. Tsirkin
2019-02-15  3:59                       ` Jason Wang
2019-02-15  4:23                         ` Michael S. Tsirkin
2019-02-19  6:21                           ` Jason Wang
2019-02-19 14:18                             ` Michael S. Tsirkin
2019-02-12 11:40           ` David Riddoch
2019-02-12 12:51             ` Michael S. Tsirkin
2019-02-12 14:01             ` Michael S. Tsirkin
2019-02-12 16:47               ` David Riddoch
2019-02-12 17:35                 ` Michael S. Tsirkin
2019-02-13  9:49                   ` David Riddoch
2019-02-13 10:33                   ` Jason Wang
2019-02-13 17:30                     ` Michael S. Tsirkin [this message]
2019-02-14  3:34                       ` Jason Wang
2019-02-14  4:04                         ` Michael S. Tsirkin
2019-02-19  6:33                           ` Jason Wang
2019-02-19 14:27                             ` Michael S. Tsirkin
2019-04-30 22:41     ` Michael S. Tsirkin
2019-06-06 12:34       ` Michael S. Tsirkin
2019-06-17 14:41         ` Michael S. Tsirkin
     [not found] <501110004.11631.1549031044295@oodm23.prod.google.com>
2019-02-01 17:43 ` Rob Miller
2019-02-04  5:36   ` Stefan Hajnoczi
2019-02-12 18:58     ` Michael S. Tsirkin
2019-02-12 18:55   ` Michael S. Tsirkin
2019-02-12 20:03     ` Rob Miller
2019-02-13 17:38       ` Michael S. Tsirkin

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=20190213121733-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=driddoch@solarflare.com \
    --cc=jasowang@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.