Repository navigation
Define / update our peer discovery strategy #174
Description
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?
Footnotes
-
or AllocateEndpoint or LearnEndpoint, but I'll just refer to SetupEndpoint to cover these too. ↩
Activity
chajasmine-bit commentedon Aug 27, 2026
The proposals look good to me. My use case is simply to support Point 3, where the remote device queries its EID over UART for MCTP data transfer. If possible, I’d like to implement Point 3 first, and then help with the remaining cases afterward.
jk-ozlabs commentedon Aug 27, 2026
@chajasmine-bit OK, thanks, one clarification though:
There is no DSP0236 protocol flow where the remote device queries its own EID. Does this refer to the remote device initiating discovery? Or something else?
chajasmine-bit commentedon Aug 27, 2026
@jk-ozlabs, thank you for your prompt reply.
I would like to clarify my case: on host boot/initialization, the host BIOS initiates discovery by sending an MCTP Discovery Notify (0x0D) control request to the BMC over UART. The BMC (mctpd), acting as the bus owner, acknowledges the notification and assigns an EID to the BIOS via Set Endpoint ID (0x01). Once assigned, BIOS and BMC communicate over MCTP.
jk-ozlabs commentedon Aug 27, 2026
OK, so the usual discovery notify flow.
chajasmine-bit commentedon Aug 27, 2026
According to the proposed strategy, I believe my use case falls under implicit / autonomous discovery on addressless links (e.g., UART/Serial).
Could you confirm if my understanding is correct? If so, I would like to upload a new PR specifically for this use case, leaving #165 to focus on the other discovery scenarios. What do you think?
jk-ozlabs commentedon Aug 27, 2026
The specification set isn't really clear on how discovery should be handled on the UART case, so we might have some flexibility here.
My general thought is that those peer-to-peer transport types could fairly simply handle automatic discovery through a periodic Get Endpoint ID command (as somewhat-suggested by DSP0236 § 8.17.6). Any response would be considered an indicator of physical presence, and so would trigger the peer enumeration and address assignment process.
We would want this configurable though; possibly using a global setting, overridable via a link-specific option.
jk-ozlabs commentedon Aug 27, 2026
(which is pretty-much the same pattern as the bridge-downstream polling mechanism)
chajasmine-bit commentedon Aug 28, 2026
How should we handle recovery on UART point-to-point links if the remote endpoint resets?
If discovery relies on periodic Get Endpoint ID commands, having the bus owner continuously poll for endpoint health might introduce unnecessary bus traffic and latency.
In this scenario, is the intention for mctpd to handle detection and recovery internally (e.g., re-evaluating after failed transactions), or should it follow the standard model of relying on an external daemon (like pldmd or nvmesensor) to trigger the D-Bus Recover() method?
jk-ozlabs commentedon Aug 28, 2026
The latter. Once a peer has been discovered, mctpd does not need to poll an endpoint, only if other some other application-layer process reports a loss in connectivity.
(and if there is no application-layer process communicating with the peer, then we don't really care whether it is up or not)
msnidhin commentedon Aug 31, 2026
Hi. My use case will be covered with this.
The mechanism to discover SMBus devices is out of scope for mctpd and I would like to use inventory mechanism for that.
For USB devices in point 3. Will it also track and recover endpoints like mctp reactor?
mctpd: add autonomous discovery for addressless links
mctpd: add autonomous discovery for addressless links