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

[Andrew Jeffery]

Hi Richard,

On Tue, 2 Jun 2020, at 02:43, Thomaiyar, Richard Marian wrote:
> All,
> 
>  MCTP specification doesn’t restrict communication without EID 
> assignment. i.e. MCTP devices can communicate with each other, even 
> without EID’s (Spec limits bridging MCTP commands only – Sec 8.2 
> Special Endpoints in DSP0236). The scenario can happen in following 
> cases

Before we jump ahead, as far as I can see this is only a problem in libmctp for 
local bus communications involving at least one device requiring dynamic 
address allocation.

Obviously that doesn't mean it's not a problem, just that there exists a class 
of configuration for which this is not an issue. Where it's not an issue we can 
follow the usual message routing path. My goal is that the flow for sending 
messages is the same regardless of whether we're communicating with static or 
dynamic devices irrespective of whether the dynamic device has formally been
assigned an address (i.e. we follow the same routing path in both cases).

For static allocation, each endpoint in the network must be aware of the 
allocated EIDs a-priori, and how this is managed is out of scope of the MCTP 
base specification. If the EID assignment is known statically then there's no 
need to worry about the special case of EID 0 as alluded to above.

Finally, conceptually, we can split the process of sending a command into
three phases for the purpose of discussing addresses:

1. Command Generation: Performed at the application layer
2. Message Routing: Performed in libmctp core
3. Message Dispatch: Performed in the libmctp binding implementation 

Keep this separation in mind. My goal is that we maintain abstractions and do 
not propagate physical layer information beyond the libmctp core. I'll try to
build the case for EID 0 being a corner case, and that we should treat it that
way in the libmctp public APIs as well (i.e. not let it impact the usual interfaces
for sending messages).

> 
> 1. MCTP Bus owner available only in Main power and not on stand-by. In 
> this case, devices are required to communicate using NULL EID, till 
> main power is applied.

Again, only for communication involving a device that requires dynamic EID 
allocation.

> 
> 2. Till the EID’s are assigned by the Bus Owner, devices can 
> communicate with NULL EID(Source & Dest). 

Agreed, except for in the static case there's no need to do this because we 
know the EIDs.

> Even Bus owner, when it sends 
> out SetEID or query GetEID, it must send with NULL EID (for Dest – Sec 
> 12.3 Set Endpoint ID, 8.17.6 – Reclaiming EID’s from hot-plug devices 
> in DSP0236)

Here's an extract from 8.17.6:

> Attempting to access each endpoint can be accomplished by issuing the Get 
> Endpoint ID command to the physical address of each device and comparing the 
> returned result to the existing entry in the routing table. If there is no 
> response to the command, or if there is a mismatch with the existing routing 
> information, the entry should be cleared and the corresponding EID or EID 
> range should be returned to the "pool" for re-assignment.

Note that it says "can be accomplished" and "or if there is a mismatch". So
"must send with NULL EID" is too strong here - if we know an EID we can
use it.

This is where breaking down the process of sending a command into the three 
phases becomes useful: The application uses the EID to specify the device it 
wants to talk to in the Command Generation phase, while the Message Routing 
phase performs the mapping of EID to physical device address. If necessary, the 
EID in the message can be substituted with 0 in the Message Routing phase.

> 
> Similarly, as EndPoint device, need physical address of the bus owner, 
> so that when SetEID is received from secondary/backup bus owner, we 
> will know what to do?

This isn't dependent on the physical address - the specification says that if a 
device receives a subsequent SetEID to the first it must respond indicating the 
EID it has already been allocated. This has no tie to the physical address of 
the device sending the SetEID command. Further, we know both the EID and the 
physical address of the device that propagated the SetEID from the received 
packet, so the local routing table should simply be updated with the information 
captured.

> (Note: Secondary / backup bus owner may send with 
> same bus owner EID, but it’s physical address will be different, and 
> device can request for force Set EID).
> 
> 3. Devices without bus owner in the network trying to communicate in 
> peer-to-peer – single / simple network. 

Again, if the EIDs have been statically assigned there's no reason not to use 
them. So again this is the case where communication involves at least one 
dynamic device.

> 
> There are also scenario’s where device’s issue Get EID command to the 
> Bus owner to do a discovery or initiate discovery based on the need. In 
> this case, there can be 2 / 3 devices which will issue this GetEID, and 
> physical addressing is the way to differentiate the same. 

Yep. And this is covered by the proposal I previously outlined to Sumanth (the 
sequence outlined near the bottom of the reply):

https://lists.ozlabs.org/pipermail/openbmc/2020-April/021293.html

The summary is that for sending messages we populate the route table with a 
provisional EID assignment before sending the message.

What we lack at the moment in libmctp is proper route table handling and an API 
to interact (add/remove/inspect) with route entries. However, continuing:

The fact that the EID is marked provisional in the routing table will cause 
libmctp core to replace the EID in the message with EID 0 before passing the 
message and the physical address to the appropriate binding.

Going the other direction, upon receiving a message with EID 0, libmctp core 
will populate the routing table with a provisional EID, replace the source EID 
0 in the MCTP header with the provisional EID, then propagate the message up 
the stack.

> 
>  This requires to pass physical addressing information to the MCTP 
> Control command layer or to the upper layer from libmctp.

I think I've demonstrated above that this might not be not necessary. Please 
poke holes in what I've proposed!

Andrew