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

[Thomaiyar, Richard Marian]

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

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.

2. Till the EID’s are assigned by the Bus Owner, devices can communicate 
with NULL EID(Source & Dest). 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)

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? (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.

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.

  This requires to pass physical addressing information to the MCTP 
Control command layer or to the upper layer from libmctp. Right now, all 
this information is dropped as part of binding to MCTP Assembly / 
disassembly before mctp_bus_rx. Hence, we need to have binding specific 
private structure in the mctp_pktbuff, which needs to tracked even along 
with MCTP Message buffer, apart from Source EID. Please comment / put 
your thoughts on the same.

Regards,

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200601/4c083a60/attachment-0001.htm>