[RFC PATCH 0/2] I3C MCTP net driver

[Winiarska, Iwona]

On Tue, 2023-05-09 at 07:42 +0800, Jeremy Kerr wrote:
> Hi Iwona,
> 
> > Wouldn't creating "mctpi3cX" network interface for each I3C device rather
> > than
> > I3C bus be a better fit to model MCTP over I3C?
> 
> Great question! A few reasons for this structure:
> 
>  - it is a closer match to existing usage of network interfaces and
>    remote endpoints (say, IP, CAN, etc): you have an interface for
>    representing the local hardware and stack state, which may provide a
>    path for any devices reachable through that hardware.
> 
>  - a simpler addressing structure: you only need one *local* MCTP
>    address (EID) for the whole bus, rather that one per remote device.
> 
>  - the presence/absence of interfaces is not dependent on what's
>    connected to the bus. If we used a netdev per remote device, users
>    would not be able to set up the local stack until a remote endpoint
>    is bound (ie, userspace would need to configure every interface on
>    i3c hot join). With this model, that stack state can persist over
>    whatever may be happening to remote devices (unplug, reset,
>    re-addressing, etc).
> 
>  - if there is ever a proposal for broadcast messages in the i3c
>    transport binding, we would have to re-write it in this structure
>    anyway.
> 
> > Why are we following the mctp-i2c approach rather than mctp-serial?
> 
> mctp-serial follows the same model: the local device is always present,
> the difference here being that no physical addressing is required.
> Routes to remote endpoints are added depending on remote endpoint state,
> but the local state is preserved regardless of what is (or is not) on
> the other end of the link.
> 
> > This would also simplify the series, as we would no longer need "mctp-
> > controller" property, and the driver would just follow the I3C class driver
> > model without the need for notifiers.
> 
> It would simplify the series, but we would be punting a lot of those
> complexities over to userspace.

Thanks for the explanation - and it makes perfect sense, I'm just worried that
it might be difficult to model certain use cases with this structure.

Specifically: 

1) This is a simplified example - the EID collision can happen further down the
network (with both I3C devices acting as bridges and having multiple MCTP
endpoints behind them), bottom line is - we're dealing two separate networks.
Since the network is a link property - do we have a way forward if we go with a
single network interface for I3C controller if we need to work in an environment
like this?

                             Network 1
                         +------------------+
                         |                  |
   Network ?             | device eid 0x12  |
+------------+     +-----+                  |
|  eid 0x11  +-----+     +------------------+
| controller |
|  eid 0x10  +-----+     +------------------+
+------------+     +-----+                  |
                         | device eid 0x12  |
                         |                  |
                         +------------------+
                             Network 2

2) This is the "normal" case. 0x11 sends MCTP message to 0x12 (by issuing IBI to
the controller). How will the routing table need to look like in order for the
message to be retransmited on the same network interface? What if we do not want
to forward? What would be the difference?

                             Network 1
                         +------------------+
                         |                  |
   Network 1             | device eid 0x11  |
+------------+     +-----+                  |
|            +-----+     +------------------+
| controller |
|  eid 0x10  +-----+     +------------------+
+------------+     +-----+                  |
                         | device eid 0x12  |
                         |                  |
                         +------------------+
                             Network 1

Thanks
-Iwona


> 
> Cheers,
> 
> 
> Jeremy