linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Don Dutile <ddutile@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Yang <weiyang@linux.vnet.ibm.com>, linux-pci@vger.kernel.org
Subject: Re: Does my understanding correct?
Date: Wed, 02 May 2012 17:05:38 -0400	[thread overview]
Message-ID: <4FA1A1A2.5090406@redhat.com> (raw)
In-Reply-To: <CAErSpo6uODF00jL6hHXbB8=f3XiG2UMr+5-5CxY2T+duQVfcTA@mail.gmail.com>

On 05/02/2012 10:59 AM, Bjorn Helgaas wrote:
> On Wed, May 2, 2012 at 12:24 AM, Richard Yang
> <weiyang@linux.vnet.ibm.com>  wrote:
>> On Mon, Apr 30, 2012 at 09:56:13AM -0600, Bjorn Helgaas wrote:
>>> On Fri, Apr 27, 2012 at 11:01 PM, Richard Yang
>>> <weiyang@linux.vnet.ibm.com>  wrote:
>>>
>> Thanks for your nice chart.
>>> I think assignments shown for the PCIe-to-PCI bridge are OK, although
>>> I would draw it like this because the bridge originates a single bus
>>> 02 that may have multiple devices attached to it (this side is PCI,
>>> not PCIe, so it really is a shared bus):
>>>
>>>                                  ^
>>>                                  |
>>>                         +--------+--------+
>>>                         |     00:02.0     |
>>>                         | PCIe-PCI bridge |
>>>                         |                 |
>>>                         +--------+--------+
>>>                                  |
>>>                                  |
>>>                       +---------------------+    Bus 02
>>>                       |                     |
>>>                       |                     |
>>>                       |                     |
>>>                  +----v----+           +----v----+
>>>                  | 02:00.0 |           | 02:01.0 |
>>>                  +---------+           +---------+
>>>
>> So for this case, there is not internal bus, while this is really a
>> physical shared bus, not a logical one.
>
> Yes.  The downstream side of the PCIe-PCI bridge is PCI.
>
>>> I think the PCIe switch part is incorrect.  Here's Figure 1-3 from sec
>>> 1.3.3 of the PCIe r3 spec:
>>
>>                                      ^
>>                                      |
>>      +-------------------------------|------------------------------+
>>      |                               |                              |
>>      |                          +----+----+                         |
>>      |                          | virtual |                         |
>>      |                          | PCI-PCI |                         |
>>      |                          | bridge  |                         |
>>      |                          +----+----+                         |
>>      |                               |                              |
>>      |                               |Bus#3                         |
>>      |                               |                              |
>>      |          +----------------------------------------+          |
>>      |          |                    |                   |          |
>>      |          |                    |                   |          |
>>      |          |03:00.0             |03:01.0            |03:02.0   |
>>      |     +----+----+          +----+----+         +----++---+     |
>>      |     | virtual |          | virtual |         | virtual |     |
>>      |     | PCI-PCI |          | PCI-PCI |         | PCI-PCI |     |
>>      |     | bridge  |          | bridge  |         | bridge  |     |
>>      |     +----+----+          +----+----+         +----+----+     |
>>      |          |Bus#4?              |                   |          |
>>      |     -----+-------             |                   |          |
>>      +----------|--------------------|-------------------|----------+
>>                 |                    |                   |
>>                 v                    v                   v
>>
>>
>>> A PCIe switch appears as two or more PCI-PCI bridges.  One is
>>> associated with the upstream port; the others with the downstream
>>> ports.
>>>
>>> A bridge always has a primary side and a secondary side.  In your
>>> diagram, the bridge associated with the upstream port would be 00:01.0
>>> (primary bus 00) and could have a secondary bus of 03 (since 02 is
>>> already consumed by the PCIe-PCI bridge).
>> Hmm... I am confused why is 03. 02 is used but 01 is not used.
>> Switch should be configured after PCIe2PCI bridge?
>
> It's likely that the PCIe switch would be configured first, since its
> device number is lower, but that is not a requirement.  The
> requirement is that the bus number ranges consumed by bridges be
> non-overlapping.  In this case (using your original topology plus my
> PCIe switch diagram), we'd have:
>
>    1. an endpoint at 00:00.0 -- consumes no additional buses
>    2. a PCIe switch at 00:01.0 -- consumes at least [bus 03-06]
>    3. a PCIe-PCI bridge at 00:02.0 -- consumes least [bus 02] (its secondary bus)
>
> Bus 03 is the internal PCIe switch bus that connects the upstream port
> to the downstream ports.  Buses 04, 05, and 06 are the links
> originating from the downstream ports.
>
>>> The bridges associated with the downstream ports are all logically on
>>> bus 03.  Their primary bus number would be 03; they might be 03:00.0,
>>> 03:01.0, 03:02.0, etc.  Each would have its own secondary bus number,
>>> for example 04, 05, 06.  That secondary bus number is for the
>>> downstream link from the corresponding downstream port.
>> Hmm, as you mentioned in previous letter, PCIe is an point-to-point
>> protocol, then the secondary bus should reside in the Switch?
>> Do you think my Bus#4 is correct?
>
> No.  Bus 04 is a PCIe link that connects the downstream port (03:00.0)
> to a single PCIe device.  That device (04:00) could be a PCIe
> endpoint, or it could be the upstream port of another PCIe switch.
> (If it is a switch, more bus numbers would be required.)
>
>>> The endpoints below the PCIe switch could then be 04:00.0 and 05:00.0
>>> (or these could be the upstream ports of more PCIe switches).
>> So below the PCIe downstream port, there is only on PCIe device.
>> The whole bus is occupied by this device?
>> That is why the device could have upto 256 functions?
>
> Yes, if it supports ARI.
>
minor tweak: if the device *and* the downstream PCIe bridge support ARI...
both must exist.  I know of one such module, e.g., non-ARI PCIe switch w/PCIe endpoints)
and the endpoints have SRIOV/VF support... not a very smart hw combo. .. nuf said.

> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2012-05-02 21:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27  9:27 Does my understanding correct? Richard Yang
2012-04-27 14:10 ` Jiang Liu
2012-04-27 15:55   ` Bjorn Helgaas
2012-04-27 14:17 ` Bjorn Helgaas
2012-04-28  5:01   ` Richard Yang
2012-04-28  7:21     ` Richard Yang
2012-04-30 15:56     ` Bjorn Helgaas
2012-05-02  6:24       ` Richard Yang
2012-05-02 14:59         ` Bjorn Helgaas
2012-05-02 21:05           ` Don Dutile [this message]
2012-05-03  6:21           ` Richard Yang
2012-05-03 16:39             ` Bjorn Helgaas
2012-05-04  2:11               ` Richard Yang
2012-05-06 15:21               ` Richard Yang
2012-05-07  3:00               ` Richard Yang
2012-04-28  8:21   ` Richard Yang

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=4FA1A1A2.5090406@redhat.com \
    --to=ddutile@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=weiyang@linux.vnet.ibm.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).