All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hawkins <dwh@ovro.caltech.edu>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Jan-Bernd Themann <THEMANN@de.ibm.com>,
	netdev@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
	Ira Snyder <iws@ovro.caltech.edu>
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
Date: Tue, 14 Apr 2009 15:27:16 -0700	[thread overview]
Message-ID: <49E50DC4.3080108@ovro.caltech.edu> (raw)
In-Reply-To: <fa686aa40904141516s1ca2965fted07bf2a6f5ce390@mail.gmail.com>

Hi Grant,

> Hmmm, I hadn't thought about this.  I was intending to use the
> Virtex's memory region for all virtio, but if I can allocate memory
> regions on both sides of the PCI bus, then that may be best.

Sounds like you can experiment and see what works best :)

>> If you use
>> a PCI Target only core, then the MPC5200 DMA controller
>> will have to do all the work, and read transfers might
>> be slightly less efficient.
> 
> I'll definitely intend to enable master mode on the Xilinx PCI controller.

Since you understand the lingo, you clearly understand
there are core differences :)

>> Our target boards (PowerPC) live in compactPCI backplanes
>> and talk to x86 boards that do not have DMA controllers.
>> So the PCI target board DMA controllers are used to
>> transfer data efficiently to the x86 host (writes)
>> and less efficiently from the host to the boards
>> (reads). Our bandwidth requirements are 'to the host',
>> so we can live with the asymmetry in performance.
> 
> Fortunately I don't have very high bandwidth requirements for the
> first spin, so I have some room to experiment.  :-)

Yes, in theory you have enough bandwidth ... then a
few features are added, the PCI core is not quite as
fast as advertised, etc etc :)

Cheers,
Dave

WARNING: multiple messages have this Message-ID (diff)
From: David Hawkins <dwh@ovro.caltech.edu>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Ira Snyder <iws@ovro.caltech.edu>, Arnd Bergmann <arnd@arndb.de>,
	Jan-Bernd Themann <THEMANN@de.ibm.com>,
	netdev@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
Date: Tue, 14 Apr 2009 15:27:16 -0700	[thread overview]
Message-ID: <49E50DC4.3080108@ovro.caltech.edu> (raw)
In-Reply-To: <fa686aa40904141516s1ca2965fted07bf2a6f5ce390@mail.gmail.com>

Hi Grant,

> Hmmm, I hadn't thought about this.  I was intending to use the
> Virtex's memory region for all virtio, but if I can allocate memory
> regions on both sides of the PCI bus, then that may be best.

Sounds like you can experiment and see what works best :)

>> If you use
>> a PCI Target only core, then the MPC5200 DMA controller
>> will have to do all the work, and read transfers might
>> be slightly less efficient.
> 
> I'll definitely intend to enable master mode on the Xilinx PCI controller.

Since you understand the lingo, you clearly understand
there are core differences :)

>> Our target boards (PowerPC) live in compactPCI backplanes
>> and talk to x86 boards that do not have DMA controllers.
>> So the PCI target board DMA controllers are used to
>> transfer data efficiently to the x86 host (writes)
>> and less efficiently from the host to the boards
>> (reads). Our bandwidth requirements are 'to the host',
>> so we can live with the asymmetry in performance.
> 
> Fortunately I don't have very high bandwidth requirements for the
> first spin, so I have some room to experiment.  :-)

Yes, in theory you have enough bandwidth ... then a
few features are added, the PCI core is not quite as
fast as advertised, etc etc :)

Cheers,
Dave

  reply	other threads:[~2009-04-14 22:27 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24  0:00 [RFC v2] virtio: add virtio-over-PCI driver Ira Snyder
2009-02-24  0:00 ` Ira Snyder
2009-02-26 16:15 ` Arnd Bergmann
2009-02-26 16:15   ` Arnd Bergmann
2009-02-26 16:53   ` Geert Uytterhoeven
2009-02-26 16:53     ` Geert Uytterhoeven
2009-02-26 20:25     ` Ira Snyder
2009-02-26 20:25       ` Ira Snyder
2009-02-26 20:01   ` Ira Snyder
2009-02-26 20:01     ` Ira Snyder
2009-02-26 20:37     ` Arnd Bergmann
2009-02-26 20:37       ` Arnd Bergmann
2009-02-26 21:49       ` Ira Snyder
2009-02-26 21:49         ` Ira Snyder
2009-02-26 22:34         ` Arnd Bergmann
2009-02-26 22:34           ` Arnd Bergmann
2009-02-26 23:17           ` Ira Snyder
2009-02-26 23:17             ` Ira Snyder
2009-02-26 23:44             ` Arnd Bergmann
2009-02-26 23:44               ` Arnd Bergmann
2009-04-21  6:09         ` Grant Likely
2009-04-21  6:09           ` Grant Likely
2009-04-14 20:28 ` Grant Likely
2009-04-14 20:28   ` Grant Likely
2009-04-14 21:23   ` David Hawkins
2009-04-14 21:23     ` David Hawkins
2009-04-14 21:45     ` Grant Likely
2009-04-14 21:45       ` Grant Likely
2009-04-14 21:52       ` David Hawkins
2009-04-14 21:52         ` David Hawkins
2009-04-14 22:16         ` Grant Likely
2009-04-14 22:16           ` Grant Likely
2009-04-14 22:27           ` David Hawkins [this message]
2009-04-14 22:27             ` David Hawkins
2009-04-14 21:53   ` Ira Snyder
2009-04-14 21:53     ` Ira Snyder
2009-06-11 14:22     ` Grant Likely
2009-06-11 14:22       ` Grant Likely
2009-06-11 15:10       ` Ira Snyder
2009-06-11 15:10         ` Ira Snyder
  -- strict thread matches above, loose matches on Subject: below --
2011-05-06 12:00 Kushwaha Prabhakar-B32579
2011-05-06 12:00 ` Kushwaha Prabhakar-B32579
2011-05-06 16:06 ` Ira W. Snyder
2011-05-06 16:06   ` Ira W. Snyder
2011-05-07  5:59   ` Kushwaha Prabhakar-B32579
2011-05-07  5:59     ` Kushwaha Prabhakar-B32579

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=49E50DC4.3080108@ovro.caltech.edu \
    --to=dwh@ovro.caltech.edu \
    --cc=THEMANN@de.ibm.com \
    --cc=arnd@arndb.de \
    --cc=grant.likely@secretlab.ca \
    --cc=iws@ovro.caltech.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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.