Repository navigation
Define / update our peer discovery strategy #174
Description
Activity
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.
@chajasmine-bit OK, thanks, one clarification though:
where the remote device queries its EID over UART
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?
@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.OK, so the usual discovery notify flow.
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?
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.
Reacted by chajasmine-bitthrough a periodic Get Endpoint ID command (as somewhat-suggested by DSP0236 § 8.17.6). Any response would be considered an indicator of physical presence
(which is pretty-much the same pattern as the bridge-downstream polling mechanism)
Reacted by chajasmine-bitHow 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?
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)
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?
- added 2 commits that reference this issue
on Sep 11, 2026
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. ↩