[Question] Get Routing Table support handling

[faizana-nvidia]

I'm opening a new thread for further discussions on support for GRTE command, this is in continuation with some of major points already discussed in #85 (comment) and #85 (comment)

Apart from complexity of involving GRTE support for Cascaded Bridge topology (which I think can be taken care in later stage), I'm curious on how are we planning to handle a case where a GRTE capable Bridge is not containing some of the endpoints entries from it's assigned pool space (for eg if something like HOST controlled GPUs are behind the bridge, in HOST off state GPUs are also in power off state thus bridge might not carry such endpoints entries in RT unless end device is visible to bridge).

As per our discussed logic, our approach for GRTE capable Bridges is to rely on RTE, which will be fetch during bridge's own discovery phase. Anything that becomes visible to Bridge in later point leading to update in its RTE list, how should this be communicated to BusOwner for new endpoint discovery?

One viable solution to this is to attempt a periodic GRTE, wanted to get your thoughts on this

[jk-ozlabs]

Anything that becomes visible to Bridge in later point leading to update in its RTE list, how should this be
communicated to BusOwner for new endpoint discovery?

The routing tables would have to be polled, yes. We don't have any other notification mechanism at present. Perhaps we would request one in a future DSP0236 revision?

This is preferred over polling the entire downstream-allocated-EID range, which we would have to do for non-GRTE-capable bridges (or, we could choose to not support those...).

[jk-ozlabs]

Although, perhaps the Routing Information Update messages might be suitable too. The response data isn't as fully-formed as the GRTE information, but might be a reasonable point to trigger a GRTE query to refresh knowledge of the downstream routes.

[faizana-nvidia]

The routing tables would have to be polled, yes. We don't have any other notification mechanism at present. Perhaps we would request one in a future DSP0236 revision?

This is preferred over polling the entire downstream-allocated-EID range, which we would have to do for non-GRTE-capable bridges (or, we could choose to not support those...).

Yes it makes sense, sure we can request one up in future revision to be addressed.

Although, perhaps the Routing Information Update messages might be suitable too. The response data isn't as fully-formed as the GRTE information, but might be a reasonable point to trigger a GRTE query to refresh knowledge of the downstream routes.

As of now my reading of spec suggests RIU is meant to be used by BusOwner to give information to the bridge, do you mean future modification in this command itself, making it use other way around as well?

[jk-ozlabs]

As of now my reading of spec suggests RIU is meant to be used by BusOwner to give information to the bridge, do you mean future modification in this command itself, making it use other way around as well?

My reading was pretty sketchy there; if it's unidirectional then that is a little less useful for this case. I wasn't proposing any particular modification.

[santoshpuranik]

The routing tables would have to be polled, yes. We don't have any other notification mechanism at present. Perhaps we would request one in a future DSP0236 revision?
This is preferred over polling the entire downstream-allocated-EID range, which we would have to do for non-GRTE-capable bridges (or, we could choose to not support those...).

Yes it makes sense, sure we can request one up in future revision to be addressed.

There is a proposal to add a new (cascaded) control notification request from the bridge to all the way to the TMBO for notifying the owner of changes to the routing table: https://github.com/DMTF/PMCI-WG/pull/1504. Yuval tells me this is slated for 1.5 version of the base spec currently. Even so, the command is optional to implement, so we would need polling GRTE if the supported spec version is less than 1.5. Even with 1.5, I wonder how the bus owner would know that the bridge will send this command, we likely need a "GetSupportedControlCommands" too.