[RFC PATCH 0/2] I3C MCTP net driver

[Jeremy Kerr]

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.

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.

Cheers,


Jeremy