Re: [PATCH net-next] net: mctp: add MCTP_OPT_ROUTE_SRCADDR getsockopt

[Jeremy Kerr]

Hi Faizan,

> > I'm not against the idea, we just need a fairly solidy justification
> > for adding user ABI that cannot be changed in future.
> 
> In theory, yes - any incoming message destined to an active local EID
> should reach an application bound to that message type. That said, I
> still find these problems with simply picking any local EID:
> 
> 1. It requires a snapshot of all available local EIDs first -
>    information the kernel already has internally via the routing
>    table, but which applications can today only get via ad-hoc mctp
>    route/addr correlation.

That's mostly equivalent what you're adding here - a facility to extract
a local address from the kernel. The mctp addr command just uses a
netlink interface to do so, rather than a sockopt.

The important difference here is the addition of the routing calculation
to filter that set of addresses to a single one.

> 2. Not every local EID is reachable from every peer, even on the same
>    network. Example from our hardware:
> 
>      BMC --USB(EID 8)--> SMA(EID 20) --I3C--> GPU(EID 30)
>      BMC also has a separate mctpi2c0 (EID 9), unrelated to the SMA.
> 
>    Reaching the GPU is a gateway route (30 -> via 20 -> via 8), which
>    mctp_route_lookup() already resolves correctly today for
>    sendmsg(). If PLDM instead picks "any" EID and gets 9, the GPU's
>    event notifications go out via I3C to the SMA - which has no
>    knowledge of EID 9 at all (it's on an unrelated bus). The packet is
>    undeliverable at the SMA itself, one hop before it would even reach
>    the BMC.

Is there any reason why the SMA can route to EID 8 but not 9?

>    I acknowledge this is implementation-specific, and additional
>    route provisioning on the bridge could help - but that still
>    requires out-of-band configuration to stay in sync with every
>    local EID. Separately, how device firmware handles Set Event
>    Receiver packets carrying an EID different from the one it saw
>    during Set Endpoint ID discovery is also implementation-defined.

If there was any expected correlation between the Set Event Receiver and
the sender of Set Endpoint ID messages, we wouldn't need the concept of
Set Event Receiver at all.

I wouldn't think that there would be any requirement for the
current-level bus-owner to be the event receiver; it's valid for the
events to be going to any other MCTP endpoint.

> 3. A picked EID doesn't stay valid - interface teardown (hot unplug)
>    removes its local EID from the available routes, and Set Event
>    Receiver is a one-shot registration with no way to detect that
>    drift later. Further events would then be silently dropped by the
>    kernel, since it has no route for the removed EID, and would never
>    reach the application.

You have the same issues with this - the source EID returned by your
sockopt may become stale too. In fact, if we're interested in solving
that issue, the way to detect that would be to listen for local address
add/remove events, which would require netlink, so we may as well use
the existing netlink interface for the original query too.

The most compelling point here is (2) - if there are particular routing
requirements that would require a specific EID for Set Event Receiver.
But the only datapoint we have for that is that there is a device that -
for some reason - is making one specific assumption about the routing
topology. Can you expand on that maybe?

The other approach may be to implement something like IP_PKTINFO, where
we would have visibility on the local EID for a *received* message.
There is a bit more precedence for that design, but it may introduce an
unnecessary send/receive operation before the EID can be determined (but
it's likely we're doing initial PLDM messaging to the event source
anyway...).

Cheers,


Jeremy