[RFC PATCH 0/2] I3C MCTP net driver

[Winiarska, Iwona]

On Wed, 2023-05-10 at 11:28 +0800, Jeremy Kerr wrote:
> Hi Iwona,
> 
> > 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
> 
> So I went digging around to see how this configuration fits with the
> MCTP standards. A bit of background, which I'm sure you're already
> familiar with, but just so we have a shared reference:
> 
> The MCTP Base spec (DSP0236) has a definition for a "MCTP bus":
> 
>     3.2.7
>     bus
>     a physical addressing domain shared between one or more platform
>     components that share a common physical layer address space
> 
> Which would mean that your two devices there are on the same MCTP bus,
> given we have shared physical address space. Our approach for the kernel
> MCTP stack is for a netdev (ie, the interface) to represent the system's
> connection to a bus.
> 
> While there's nothing explicitly defining whether a MCTP bus is required
> to only host one MCTP network, all of the example topologies in DSP0236
> seem to assume so.
> 
> Then: the MCTP I3C Transport Binding spec (DSP0233) introduces a
> "logical bus" term, but with no formal definition. This would cover your
> model above, where the two devices are on different logical busses, but
> the same MCTP bus. There's an example of that in Figure 3.
> 
> However, there's still no clarification on whether these logical buses
> can be on separate networks (and so operate within a separate EID
> space). In fact, the Figure 3 example *requires* the logical busses to
> be on the same network, as the Top Level Bus Owner exists on a separate
> logical bus to its owned devices.
> 
> [There are also a couple of inconsistencies in this part of DSP0233;
> there's a reference to "bridging between networks", which isn't possible
> with the definitions of "bridging" and "network", as well as a footnote
> that contradicts the definition of a MCTP bus. I'll see if I can chase
> up some clarifications to those]
> 
> Anyhow: it doesn't seem to be prohibited by the standard, but I'm not
> seeing much in the way of allowing it either. I'm happy to go by the
> assumption that it's allowed, but it does seem unnecessarily eclectic to
> me.
> 
> Back to the figure 3 example, and assuming we want to preserve the
> existing concept of the netdev being the connection to a bus: this
> *requires* us to implement the netdev-per-bus (rather than
> netdev-per-remote-endpoint) model as proposed in this series, as there
> is the shared logical bus between multiple remote endpoints.
> 
> In order to represent your use-case of multiple logical busses, I would
> propose that we use a similar model to how logical ethernet interfaces
> (ie, VLANs) are already implemented in Linux. Under that model, we could
> allow new (logical) interfaces to be created as subordinate to the
> existing (actual) interfaces, which would represent the system's
> connection to a *logical* bus, and provide the mapping to a MCTP network.
> 
> For that, we would need a bit of netlink definition to allow
> construction of the logical-bus netdev. I *think* we could then use the
> existing neighbour table definitions to provide the partitioning of
> devices over logical busses.
> 
> However: I would think it would be much simpler to just put the two
> devices on the same i3c bus on the same MCTP network, and assign
> distinct EIDs. Whether those devices could communicate can be defined by
> bridging policy.

The only reason why I believe it would be possible for someone to come up with
such network layout would be the limited amount of EIDs available in MCTP 1.x,
in which case putting everything in the same MCTP network won't be an option.

I'm bringing this up, since I originally considered device-driver model that
goes with network controller per I3C device.
I think this is the only case in which it can be more complicated to model.
I just want to avoid a situation where we paint ourselves into a corner, and the
VLAN-like approach sounds good to me (if we ever end up needing it).

> 
> On to that, while slightly re-ordering your questions:
> 
> > 2) This is the "normal" case.
> > 
> >                              Network 1
> >                          +------------------+
> >                          |                  |
> >    Network 1             | device eid 0x11  |
> > +------------+     +-----+                  |
> > >            +-----+     +------------------+
> > > controller |
> > >  eid 0x10  +-----+     +------------------+
> > +------------+     +-----+                  |
> >                          | device eid 0x12  |
> >                          |                  |
> >                          +------------------+
> >                              Network 1
> > 
> > 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?
> 
> There are a couple of options here:
> 
>  * we set a "forwarding" boolean flag on the network, which specifies
>    whether or not packets would be forwarded by the controller (acting
>    as a bridge)
> 
>  * individual routes could be configured with bridging policy: in this
>    case, the input interface and/or the source EIDs.
> 
> The former is definitely simpler, and was what I had originally
> intended, but may not cover all use-cases. I'd be interested in your
> thoughts there.

Currently, I don't see any use cases where a "forwarding" boolean flag wouldn't
be enough, but we can go back to this in the future when we add bridging
support. 

Thanks
-Iwona

> 
> Cheers,
> 
> 
> Jeremy