MCTP Null EID - Physical addressing support - Binding private in API

[Thomaiyar, Richard Marian]

Andrew,

inline comments,

Regards,

Richard

On 7/6/2020 8:43 AM, Andrew Jeffery wrote:
>
> On Fri, 5 Jun 2020, at 12:53, Thomaiyar, Richard Marian wrote:
>> Thanks Andrew,
>>
>> inline comments. Captured this as an agenda for our next work group
>> call discussion https://github.com/openbmc/openbmc/wiki/OpenBMC-PMCI-WG
> I noted in another thread that I've pushed patches implementing bridging and
> routing along with the provisional EID concept to gerrit:
>
> https://gerrit.openbmc-project.xyz/q/topic:%2522routing%2522+(status:open+OR+status:merged)+project:openbmc/libmctp
>
> In the end the implementation uses a "provisional" flag in both the mctp_eid_t
> type and the route table as there was one race that couldn't be safely
> eliminated without it.
>
>> [Richard]: We
>> can't know which EID can be used as provisional. It may be real EID in
>> a bridged network. Please educate me, if the same can be achieved
>> without having a conflict.
> Because the conflict shouldn't matter - it can be detected by the binding
> receiving the message by looking up the source EID in the route table and
> checking if the result is a provisional EID.
>
> However, the complication occurs when trying to remove the provisional EID from
> the route table in order to deliver the message received from the endpoint that
> has been formally allocated the same EID. If there's an outstanding command
> whose response hasn't yet been sent which will need the provisional EID entry
> from the table in order for the message to be routed, we can't deliver the
> message received from the endpoint which is non-provisionally assigned the EID.
> It's hard to unwind that properly and still account for issues like deadlocks
> or application crashes which will lead to a denial of service.
>
> So the result is we have a route table with two separate address spaces, one
> for formally assigned EIDs and another for provisional EIDs. This partition is
> managed by a flag on the route table entries in the current implementation.

[Richard]: Reviewed the same and indicating provisional EID using the 
flag will cause confusion, as application must use this flag. 
Applications can't just rely on EID 0 is special, instead it must check 
for the flag.

Won't it be easier to track with EID 0 itself, as all application knows 
that it is special EID (no separate EID necessary), and applications 
using special EID, must be aware about which device it is communicating 
and should be fine.

I also see that with provisional EID, we are building up of another EID 
concept similar to MCTP specification, and don't find a way to clear it. 
We are doing on the assumption that provisional EID will be removed once 
proper EID is assigned, but we will end up issuing Get Endpoint ID to a 
device with Null EID (just to make sure that the card has not changed 
the EID when BMC is in reset - This will happen, when Card also went for 
a reset or swapped and it is using a static EID X, in which case BMC 
request with already assigned EID Y will be dropped).

>
> Andrew