Currently, our strategy for discovering peer endpoints is pretty simple: we don't perform any automatic peer discovery, and rely on external callers to SetupEndpoint1. Even peer-to-peer links require a SetupEndpoint to discover the peer.
However, we also want to enable a Discovery Notify flow (see #165 and #159), where an entirely in-band event - the reception of a Discovery Notify message - triggers discovery, resulting in a peer being published.
Those two PRs are reasonable, but don't really consider a complete design for the new discovery mechanism. This issue is for addressing a whole-system design that includes a Discovery Notify flow.
So, an initial proposal:
- Some link types will require an external mechanism for discovery. For example, SMBus - where we do not have an indication of target devices ourselves, and so rely on something like SMBus ARP, or an external inventory mechanism, to trigger discovery
- Some link types (PCIe VDM, i3c in some topologies) use the Discovery Notify facility, which we can use to trigger enumeration
- Some link types (serial, USB) do not have any physical addressing requirements, and so may allow discovery with no external trigger
- We will always need to support inventory-based discovery for all link types
(1) and (4) mean that the SetupEndpoint calls will always remain available; either for discovery though external mechanisms (like SMBus ARP, or inventory data)
For (2), the aforementioned PRs should cover those cases
For (3), we can implement an implicit discovery process for links that do not require additional addressing data. In cases where mctpd is the bus owner, this would be a periodic Get Endpoint Id, resulting in peer discovery when a remote endpoint is available to respond.
I think we would need a configuration facility to enable/disable the automatic peer discovery flows, but I am open to suggestions on that.
@chajasmine-bit, @msnidhin : any thoughts on the above? Can you provide some information on your use-cases for peer discovery?
Currently, our strategy for discovering peer endpoints is pretty simple: we don't perform any automatic peer discovery, and rely on external callers to SetupEndpoint1. Even peer-to-peer links require a SetupEndpoint to discover the peer.
However, we also want to enable a Discovery Notify flow (see #165 and #159), where an entirely in-band event - the reception of a Discovery Notify message - triggers discovery, resulting in a peer being published.
Those two PRs are reasonable, but don't really consider a complete design for the new discovery mechanism. This issue is for addressing a whole-system design that includes a Discovery Notify flow.
So, an initial proposal:
(1) and (4) mean that the SetupEndpoint calls will always remain available; either for discovery though external mechanisms (like SMBus ARP, or inventory data)
For (2), the aforementioned PRs should cover those cases
For (3), we can implement an implicit discovery process for links that do not require additional addressing data. In cases where mctpd is the bus owner, this would be a periodic Get Endpoint Id, resulting in peer discovery when a remote endpoint is available to respond.
I think we would need a configuration facility to enable/disable the automatic peer discovery flows, but I am open to suggestions on that.
@chajasmine-bit, @msnidhin : any thoughts on the above? Can you provide some information on your use-cases for peer discovery?
Footnotes
or AllocateEndpoint or LearnEndpoint, but I'll just refer to SetupEndpoint to cover these too. ↩