qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: Giuseppe Lettieri <giuseppe.lettieri@iet.unipi.it>,
	qemu-devel@nongnu.org, v.maffione@gmail.com
Subject: Re: [Qemu-devel] bypassing pci_dma_read() and pci_dma_write() ?
Date: Fri, 18 Jan 2013 17:14:02 +0100	[thread overview]
Message-ID: <50F974CA.8010603@redhat.com> (raw)
In-Reply-To: <20130118160448.GA76938@onelab2.iet.unipi.it>

Il 18/01/2013 17:04, Luigi Rizzo ha scritto:
> Hi,
> with a bunch of e1000 improvements we are at a point where we are
> doing over 1Mpps (short frames) and 7-8Gbit/s (1500 byte frames)
> between two guests, and two things that are high in the "perf top"
> stats are phys_page_find() and related memory copies.
> 
> Both are triggered by the pci_dma_read() and pci_dma_write(),
> which on e1000 (and presumably other frontends) are called on
> every single descriptor and every single buffer.
> 
> I have then tried to access the guest memory without going every
> time through the page lookup. [...]
> 
> This relies on the assumption that the ring (which is contiguous in the
> guest's physical address space) is also contiguous in the host's virtual
> address space.  In principle the property could be easily verified once
> the ring is set up.

IIRC, the amount of contiguous memory is written by address_space_map in
the plen parameter.

In your case:

>     +       s->txring = address_space_map(pci_dma_context(&s->dev)->as,
>     +                       base, &desclen, 0 /* is_write */);

that would be desclen on return from address_space_map.

> And of course, am i missing some important detail ?

Unfortunately yes.

First, host memory mappings could change (though they rarely do on PC).
 The result of address_space_map is not guaranteed to be stable.  To
avoid problems with this, however, you could use something like
hw/dataplane/hostmem.c and even avoid address_space_map altogether.

Second, that pci_dma_*() could have the addresses translated by an
IOMMU.  virtio is documented to have "real" physical memory addresses,
but this does not apply to other devices.

Paolo

> Of course the above could be used conditionally if the required
> conditions hold, and then revert to the pci_dma_*()
> in other cases.
> 
> cheers
> luigi
> 
> 

  reply	other threads:[~2013-01-18 16:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18 16:04 [Qemu-devel] bypassing pci_dma_read() and pci_dma_write() ? Luigi Rizzo
2013-01-18 16:14 ` Paolo Bonzini [this message]
2013-01-18 16:33   ` Luigi Rizzo
2013-01-18 16:49     ` Paolo Bonzini
2013-01-19  0:58   ` Luigi Rizzo

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=50F974CA.8010603@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=giuseppe.lettieri@iet.unipi.it \
    --cc=qemu-devel@nongnu.org \
    --cc=rizzo@iet.unipi.it \
    --cc=v.maffione@gmail.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 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).