Repository navigation
[Question]Can we consider exposing local eid associated to remote peer as part of interface property #147
Description
The PLDM SetEventReceiver command requires configuring a terminus with the Event Receiver's EID (as request message payload eventReceiverAddressInfo ), which the terminus then uses as the destination for all subsequent event notifications to the BMC. To fulfill this, we need a straightforward way to determine the local EID that a remote endpoint should address when sending asynchronous event messages.
Currently, it is possible to manually correlate a remote endpoint's EID with the interface it is routed through and the local EID assigned to that interface, using the mctp tool. For example, remote EID 10 is routed via the musb1_1_1_1_1 interface, which has local EID 8:
$mctp route show
eid min 10 max 10 net 1 dev musb1_1_1_1_1 mtu 68
$mctp addr show
eid 8 net 1 dev musb1_1_1_1_1
However, this is a multi-step lookup, and applications like PLDM need this information readily available. Could we consider publishing the local EID as part of the xyz.openbmc_project.MCTP.Endpoint interface (or another existing/new interface) on each endpoint object?
The au.com.codeconstruct.MCTP.Network1 interface already exposes all local EIDs for a given network, but since multiple local EIDs in the range [0x08, 0xFE] may be assigned across different interfaces, there is no direct way for an application to determine which local EID corresponds to a specific remote endpoint. Publishing this association per-endpoint would eliminate the manual lookup and directly satisfy the PLDM requirement.
Activity
jk-ozlabs commentedon Mar 18, 2026
Sure, we could do that, but we would first need to define the policy for which local EID is selected, when there are multiple.
santoshpuranik commentedon Mar 18, 2026
Could you elaborate on the policy needed?
Isn't there always a 1:1 mapping between
a) A remote EID and the interface used to transmit to it (the route).
b) The local EID for that same interface.
So there is no need to choose the local EID to use?
jk-ozlabs commentedon Mar 18, 2026
No, interfaces may have multiple addresses assigned.
jk-ozlabs commentedon Mar 18, 2026
Also:
there may be multiple routes to a remote eid (which then may route through different interfaces). it's not common now, but may be when route metrics are introduced.
jk-ozlabs commentedon Mar 18, 2026
It may be simpler to just pick any local EID as your PLDM event receiver (provided its on the same MCTP network, of course). They should all be routable from the PLDM event source, right?
In that case, you don't need any new interfaces.
faizana-nvidia commentedon Mar 18, 2026
yeah makes sense to me, also stored interface index of remote peer should be enough to find local EID too.
If we go by this policy, which interface do you think should be right place to publish it?
santoshpuranik commentedon Mar 18, 2026
Okay! Why would we want to do that, though? And if we do (and they belong to the same network) I guess we could just pick any one there to send as the even receiver EID
Ack.
If the network consists of multiple interfaces (ex mctpi2cx and mctpi2cy), each with their own local EIDs, we can't assume the device on one bus can address the otehr local EID, right? Or do you think in such a case they should simply be on different networks?
jk-ozlabs commentedon Mar 19, 2026
My point was that no new information needs to be published there. You have the set of local EIDs available already, it would be the application's own policy on picking one.
jk-ozlabs commentedon Mar 19, 2026
On a properly set-up MCTP network, I would think that is a valid assumption. The EID space (on any particular network) is typically globally-accessable - so the "other" local EID is reachable as long as the PLDM Event source has complete routing information.
[If that's not a valid assumption though, please let me know]
jk-ozlabs commentedon Mar 19, 2026
That said, if the local EID data on dbus is awkward to consume, we can certainly provide better interfaces if necessary.
Alternatively: the kernel routing tables are the ultimate source of truth here, in that they define which source address gets populated for outgoing messages. We could potentially implement a sockopt/ioctl to query the saddr that would be used for a particular destination EID.
santoshpuranik commentedon Mar 24, 2026
This seems like the best option to me. We would need PLDM maintainers to agree review this proposal too, I think. Given that apps already use the socket API, a documented socket option seems reasonable to me.
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
10 remaining items
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt
net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt