Re: Query regarding ARI configuration of a on-board PCIe device.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 9, 2014 at 12:16 PM, Scott Lurndal <kdb@xxxxxxxxxxx> wrote:
> Bjorn Helgaas <bhelgaas <at> google.com> writes:
>
>>
>> On Thu, Jan 9, 2014 at 3:51 AM, Sunil Kovvuri <sunil.kovvuri <at>
> gmail.com> wrote:
>> > Hi,
>> >
>> > I have a platform which has a on-board PCIe device attached to PCIe port.
>> > This device is an ethernet device with SRIOV capability having morethan
>> > 8 virtual functions.
>> >
>> > I am going through Linux's ARI configuration code and saw that it is
> checking
>> > if upstream bridge supports ARI or not. In our case its a on-board
> device and
>> > no bridge is involved.
>> >
>> > Need some help or ideas on how i can configure ARI on the device so that
>> > all VFs gets added.
>> >
>> > Do i need to change the ARI configuration code or is there a way to fake a
>> > PCI bridge for this purpose ?
>>
>> I assume you're referring to pci_configure_ari().  A PCIe endpoint
>> such as your ethernet device always has an upstream bridge.  In your
>> case, the device is on-board and there's no PCIe switch involved, but
>> the root port is the upstream device, and it is handled as a bridge.
>>
>> It looks like pci_configure_ari() should enable ARI by default when it
>> is supported.  But apparently it isn't being enabled on your system?
>> Can you collect the "lspci -vv" output for the root port and the NIC?
>>
>> Bjorn
>>
>
>
> Hi Bjorn,
>
>    For the sake of discussion, let's assume that the device in question,
> which is intended to appear to software as a pci-express SR-IOV device
> with more than 8 functions (i.e. ARI), has a PCI-Express configuration
> space which is slotted into an ECAM region for discovery and
> configuration.  The device itself is directly attached to the host-bridge
> and doesn't have an associated root port.
>
>    In this case, the check for bridge in pci_configure_ari() is
> problematic because there is no root port (the host bridge is
> transparent to software).

I don't think the topology you describe is legal.  A directly-attached
device that is not part of the hierarchy below a Root Port would have
to be a Root Complex Integrated Endpoint.  The device would indicate
its support for ARI with an ARI extended capability, but the spec (sec
7.23) says an Integrated Endpoint can't have an ARI capability.

If I understand ARI correctly, an endpoint has to indicate support for
it with the ARI capability, but you actually enable support for it in
the downstream port leading to the endpoint (assuming *it* also
supports ARI).

I guess if you posit an integrated endpoint with an ARI capability, I
could imagine an ARI-enable switch in the host bridge, but that's not
architected, so there would have to be host bridge driver code to
enable it.

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




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux