mctpd: Add EIDs property to show local EIDs

[ThuBaNguyen]

Add code to show the local EIDs in EIDs property in au.com.CodeConstruct.MCTP.Interface1 D-Bus interface.

busctl introspect au.com.codeconstruct.MCTP1 /au/com/codeconstruct/mctp1/interfaces/mctpi2c3
NAME                                 TYPE      SIGNATURE RESULT/VALUE FLAGS
au.com.CodeConstruct.MCTP.Interface1 interface -         -            -
.EIDs                                property  ay        1 8          const

[amboar]

I'm not trying to block the change here, but I feel we might want a holistic treatment of Figure 9 from DSP0236 v1.3.3. I feel that requires a bit more thought about how EID associations are represented. I don't think the proposal is wrong as such, but it is incomplete.

[jk-ozlabs]

From some chatting on Discord, my suggested approach was that we have an EIDs property on the network object, where an application can always pick the first to acquire a suitable local EID that can route to the local stack. Since the host will accept any local destination EID, it will always be valid on any incoming interface.

(the extension of that concept is that we may as well assign the same local EID to all interfaces, but that's entirely optional)

We may have a scenario in future where an application may need to query a local EID that is bound to a specific interface, but I don't think that's what's happening here.

[ThuBaNguyen]

From some chatting on Discord, my suggested approach was that we have an EIDs property on the network object, where an application can always pick the first to acquire a suitable local EID that can route to the local stack.

It seems I missed your idea in the Discord Chat. I thought we will add the EIDs property to au.com.CodeConstruct.MCTP.Interface1 D-Bus interface of interface D-Bus object such as /au/com/codeconstruct/mctp1/interfaces/mctpi2c3

In case, we want to add the EIDs property to network object path such as /au/com/codeconstruct/mctp1/networks/1, I wonder which D-Bus interface should we use to add EIDs property?

root@mtmitchell-dcscm:~# busctl introspect au.com.codeconstruct.MCTP1 /au/com/codeconstruct/mctp1/networks/1
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -
org.freedesktop.DBus.Peer           interface -         -            -
.GetMachineId                       method    -         s            -
.Ping                               method    -         -            -
org.freedesktop.DBus.Properties     interface -         -            -
.Get                                method    ss        v            -
.GetAll                             method    s         a{sv}        -
.Set                                method    ssv       -            -
.PropertiesChanged                  signal    sa{sv}as  -            -

Since the host will accept any local destination EID, it will always be valid on any incoming interface.

I'm agree with you that when the interfaces are belong to the same network, this will be true. Although, this will make the routing table in both BMC, the bridge between BMC and terminus (if have) and the terminus are more complicated.
Ampere team is still evaluating this solution. I will give more opinions in this solution later.

(the extension of that concept is that we may as well assign the same local EID to all interfaces, but that's entirely optional)

This option can only be applied when BMC is BO in all interfaces.

We may have a scenario in future where an application may need to query a local EID that is bound to a specific interface, but I don't think that's what's happening here.

[ThuBaNguyen]

From some chatting on Discord, my suggested approach was that we have an EIDs property on the network object, where an application can always pick the first to acquire a suitable local EID that can route to the local stack. Since the host will accept any local destination EID, it will always be valid on any incoming interface.

What do you think about adding the D-Bus interface "au.com.CodeConstruct.MCTP.Network1" in network object path as below

 busctl introspect au.com.codeconstruct.MCTP1 /au/com/codeconstruct/mctp1/networks/1
NAME                                TYPE      SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface -         -            -
.Introspect                         method    -         s            -
org.freedesktop.DBus.Peer           interface -         -            -
.GetMachineId                       method    -         s            -
.Ping                               method    -         -            -
org.freedesktop.DBus.Properties     interface -         -            -
.Get                                method    ss        v            -
.GetAll                             method    s         a{sv}        -
.Set                                method    ssv       -            -
.PropertiesChanged                  signal    sa{sv}as  -            -
au.com.CodeConstruct.MCTP.Network1  interface -         -                                      -
.EIDs                               property  ay        2 8 12                                    const

Where:

1. au.com.CodeConstruct.MCTP.Network1 is interface name. 1 is version.
2. There is one properties in the network D-Bus interfaces:
   a) EIDs will be BMC local EIDs in the network 1 as we discuss before.

[jk-ozlabs]

Looks good, but maybe make it obvious that the EIDs are local to this endpoint? we could name it LocalEIDs, perhaps?

[ThuBaNguyen]

Looks good, but maybe make it obvious that the EIDs are local to this endpoint? we could name it LocalEIDs, perhaps?

Sure. LocalEIDs is more details property name.

[jk-ozlabs]

ok, super. Also, just check the capitalisation on the interface name.