All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Eric Wehage <Eric.Wehage@huawei.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	Linuxarm <linuxarm@huawei.com>,
	Stephen Bates <sbates@raithlin.com>
Subject: Re: [RFC] Proposed PCI ECR for description of Advanced Peer to Peer Capabilities
Date: Thu, 13 Dec 2018 09:23:48 +0000	[thread overview]
Message-ID: <20181213092348.00004105@huawei.com> (raw)
In-Reply-To: <41f870ad-2255-4840-34b1-eff0d20b993d@deltatee.com>

On Mon, 10 Dec 2018 12:39:36 -0700
Logan Gunthorpe <logang@deltatee.com> wrote:

> On 2018-12-10 12:36 p.m., Eric Wehage wrote:
> > There are 5 TLP types described in each of the three P2P Routes. I'm
> > not sure that anyone would care about Message Bandwidth, so I
> > could simply add 3 bits to each Route register indicating whether the
> > P2P route bandwidth supports the same or more bandwidth than if it
> > targeted DRAM.
> > 
> > The three RO/HWInit bits for each route register would be:
> > - P2P Memory Read Bandwidth is equal to or greater than to Main
> >    Memory
> > - P2P Memory Write Bandwidth is equal to or greater than to Main
> >    Memory
> > - P2P Memory AtomicOp Bandwidth is equal to or greater than to Main
> >    Memory  
> 
> Yeah! That sounds great. Thanks.
> 
> Logan

Updated ECR and presentation at:
Presentation: https://drive.google.com/open?id=1fgwz8w32K2ju9aIySP8RXwQwUAcT9icF
ECR: https://drive.google.com/open?id=1cHn4OHgTJpa0KkiVab_CyK1NMjPap3MM

A few small editorial bits and pieces.

The main change is making the Memory Read, Memory Write and Atomic capabilities
in addition to indicating they support peer to peer at all, can now give an
indication of supporting 'same bandwidth as to system memory'.

Note that from a PCI viewpoint system memory really means anything beyond the
host so caches etc are all rolled into that term.

Thanks,

Eric and Jonathan


  reply	other threads:[~2018-12-13  9:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 11:56 [RFC] Proposed PCI ECR for description of Advanced Peer to Peer Capabilities Jonathan Cameron
2018-12-10 17:20 ` Logan Gunthorpe
2018-12-10 18:02   ` Eric Wehage
2018-12-10 19:01     ` Logan Gunthorpe
2018-12-10 19:06       ` Stephen  Bates
2018-12-10 19:36       ` Eric Wehage
2018-12-10 19:39         ` Logan Gunthorpe
2018-12-13  9:23           ` Jonathan Cameron [this message]
2018-12-13 16:51             ` Logan Gunthorpe
2018-12-10 19:21 ` Alexander Duyck

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=20181213092348.00004105@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Eric.Wehage@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=logang@deltatee.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=sbates@raithlin.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.