pcie modeling guidance | Redfish Specification Forum

radsquirrel
Minnow

Posts: 4

pcie modeling guidance Aug 23, 2021 20:35:42 GMT

Quote

Post by radsquirrel on Aug 23, 2021 20:35:42 GMT

This is my first post, please feel free to let me know if I'm breaking any etiquette protocol.

My system and Redfish implementation will have pcie slots, with populated location properties. My system also has multiple processor FRUs (each with multiple embedded pcie root complexes), also with populated location properties.

I would like my API clients to be able to traverse from the pcie slot location back to location of the processor that contains the root complex associated with the slot. I've been staring at the PCIe fabric mockups but I can't piece together how this relationship is intended to look. A couple things that might have taken me off-course:

- the fabric schema says "one or more switches" so it doesn't seem to be applicable here - there is just the pcie root complex and the slot on the other side.
- If I assume for a moment its OK for a PCIe fabric to have zero switches, even then I don't see any links in the Endpoints schema that help me traverse from pcie slot to processor fru.

thx for your help!

-brad

jautor
Administrator

Posts: 519

pcie modeling guidance Aug 24, 2021 22:35:42 GMT

Quote

Post by jautor on Aug 24, 2021 22:35:42 GMT

Hi Brad,

For "simple" systems with PCIe slots that have some affinity to a processor (multiple root complexes off separate processors), we can add a link to the Processor from the Slots[] in PCIeSlot, but I do want to name that property appropriately so that it only gets populated by systems that actually benefit from that information. Meaning, for single-root-complex systems, there's nothing useful to be gained from those links...

We'll open an issue with the Forum to get this added to the schema.

For more complicated designs, the PCIe Fabric model is probably needed, and you'd probably need to do a mockup to make sure we have all the links covered...

Jeff

radsquirrel
Minnow

Posts: 4

pcie modeling guidance Sept 8, 2021 17:26:54 GMT

Quote

Post by radsquirrel on Sept 8, 2021 17:26:54 GMT

> For "simple" systems with PCIe slots... [snip]
> We'll open an issue with the Forum to get this added to the schema.

that all makes sense Jeff, thanks.

> For more complicated designs, the PCIe Fabric model is probably needed

I never described my "more complicated design" and the full requirements of what I'm trying to do here so let me do that now. Basically I have a "pcie multiplier/expander", spread across three physical devices:

1 - a dumb pcie device installed in a pcie slot in a server chassis, that more or less routes the internal pcie connectors to an external oculink port that connects to
2 - an oculink cable, that connects to
3 - a downstream port in an assembly in a different chassis ("a box of pcie slots"), that has a pcie switch with its outputs connected to the slots

I would like to be able to show the connections between the slot with the dumb device, the cable and the slots on the other side behind the switch.

In my research I ran across this statement:

"fabrics are built on the concept of sending and receiving messages without shared memory between the end points." (https://www.nvmexpress.org/wp-content/uploads/NVMe_Over_Fabrics.pdf)

In my case this is definitely not the case - everything is backed by shared memory. This makes me think that Fabrics/Switches/Endpoints are not the right tool for me. Would you agree? If so, any tips on how to model those relationships?

thanks!

-brad

Last Edit: Sept 8, 2021 17:36:19 GMT by radsquirrel