Open ThuBaNguyen opened 1 week ago
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.
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.
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.
Add code to show the local EIDs in
EIDs
property inau.com.CodeConstruct.MCTP.Interface1
D-Bus interface.