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

[Thomaiyar, Richard Marian]

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

Regards,

Richard

On 6/5/2020 7:51 AM, Andrew Jeffery wrote:
> Hi Richard,
>
> I've trimmed out all the bits we agree on.
>
> On Thu, 4 Jun 2020, at 19:35, Thomaiyar, Richard Marian wrote:
>> On 6/3/2020 8:10 AM, Andrew Jeffery wrote:
>>> 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.  [Richard]: Intentionally didn't talk about static
>> EID - networks as this problems won't be there. If you meant to say
>> that libmctp is not designed to handle non-static network case, let me
>> know. I brought this topic to cover it in libmctp.
> Let's not get ahead of ourselves :)
>
> I _intend_ libmctp to handle non-static network cases just fine. We need to do
> some work though, mainly implementing support for routing.
[Richard]: we are on the same page then.
>>>> 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.  [Richard]: Yes.
>>>> 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.  [Richard]: Now for dynamic only EID case, how this will
>> happen is the question here.
> It is handled by the provisional EID proposal.

>>>> 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.
>>   [Richard]: Not really. This section 8.17.6 talks about reclaiming. i.e
>> Basically, in this case, don't send GetEID command based on EID to
>> physical address mapping, instead send GetEID to the needed physical
>> address with Dest EID Null, and cross verify it's EID.
> That's an option but not a necessity as far as I read it. And if it's not a
> necessity, we can still use our current understanding of the EID to perform the
> EID to physical address mapping in the routing phase. If we're unsure of the
> device's assigned EID, we can always mark what know as was its previous address
> as provisional before sending the GetEID command. The provisional mark will
> cause the routing layer to replace the message's destination EID with 0 after
> resolving the physical address.

[Richard]: If you are saying to use different flag / field, apart from 
mctp_eid_t for it, then we are on the same page here, and can talk about 
how that must be done. The main agreement we need to make here is 
whether same mctp_eid_t must be used or not.

>> This needs to be
>> performed, to figure out whether EID of the device changed due to card
>> replacement or reset etc. If we don't send with Dest EID as 0, then
>> device may drop the packet, if there is mismatch with it's EID.
> This is why in the provisional EID proposal we substitute the supplied EID with
> 0 in the routing layer.

>>>> 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.  [Richard]: Not really, if the same bus owner sends SetEID,
>> we need to accept that, but if the request comes from different one,
>> then we can't accept that one. Assume bus owner crashed / reset and
>> coming back up, it may start with different EID assignment, based on
>> number of devices at that point and devices needs to identify the bus
>> owner with UUID or physical address to uuid mapped.
> This isn't what the spec says as I read it. Can you point to the sections that
> made you come to this conclusion about the specific device that's acting as bus
> owner?

[Richard]: yes, in section 12.3 of the DSP0236. Capturing the excerpt below.

The Set Endpoint ID command is also used to provide the Physical Address 
and EID of the Bus Owner to
an Endpoint. An Endpoint that needs to communicate with the Bus Owner 
may capture the physical
address and EID that was used to deliver the Set Endpoint ID message.

>
>>> 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.
>>   [Richard]: This means that Provisional EID is carved out of the EID
>> Pool. With bridging - (Multiple networks), this can't be handled. We
>> will end up with real EID for the same provisional EID, and hence we
>> won't know when we send back data to which device we need to deliver.
> This case can be detected by the routing layer, however I need to think through
> the impacts some more. I don't think it precludes the provisional EID approach.
> To get a bit more specific, provisional EIDs are only used above the routing
> layer where an inbound message contains a 0 source EID, and for the outbound
> case where the destination EID should be 0. If an inbound message arrives with
> a non-zero source EID then we know it is a legitimately assigned EID and we can
> de-conflict the routing table.
>
> I just need to make sure this works for each scenario.
[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.
>
>>>>   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!
>> [Richard]:
>>
>> _*For control command handling:*_ As stated, we need a mechanism other
>> than EID (Note: I meant we may need to introduce one more field, to
>> make the difference - if you are saying that as provisional (i.e. not
>> the same mcpt_eid_t then that's what we are saying as binding private).
>>
>> _*Now for other Message types*_ say PLDM etc. Other than EID, PLDM
>> doesn't use any of the MCTP Transport header, but we still need to
>> expose the transport header in the upper API, as other OEM types may
>> use it or rely on MCTP transport header for informaiton.
> Can you please provide concrete examples of this being necessary?
[Richard]: For control commands, already stated the scenarios and 
excerpt from specification, let me know if you are looking for any other 
specific concrete examples.
>
>> Now, having
>> said there are cases where devices behind mux
> For muxes it should be possible to determine the necessary mux state between
> the routing and the binding. The mux configuration should be encoded as part of
> the physical address. This may mean we need binding "decorators" to handle the
> case.
>
>> or requires special
>> handling, now we need to see how to handle the same in terms of API
>> (which is second part of this discussion).
> Can you please be more specific here? What do you have in mind?
>
> Cheers,
>
> Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200605/b9cd4970/attachment.htm>