[Question]Can we consider exposing local eid associated to remote peer as part of interface property

[faizana-nvidia]

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.

[jk-ozlabs]

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]

Sure, we could do that, but we would first need to define the policy for which local EID is selected, when there are multiple.

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]

b) The local EID for that same interface.

No, interfaces may have multiple addresses assigned.

[jk-ozlabs]

Also:

a) A remote EID and the interface used to transmit to it (the route).

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]

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]

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]

No, interfaces may have multiple addresses assigned.

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

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.

Ack.

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?

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]

If we go by this policy, which interface do you think should be right place to publish it?

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]

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?

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]

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.