Re: WWAN Controller Framework (was IPA [PATCH v2 00/17])

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2019-06-24 at 12:06 -0500, Alex Elder wrote:

> > OK I want to try to organize a little more concisely some of the
> > discussion on this, because there is a very large amount of volume
> > to date and I think we need to try to narrow the focus back down
> > again.

Sounds good to me!

> > I'm going to use a few terms here.  Some of these I really don't
> > like, but I want to be unambiguous *and* (at least for now) I want
> > to avoid the very overloaded term "device".
> > 
> > I have lots more to say, but let's start with a top-level picture,
> > to make sure we're all on the same page.
> > 
> >          WWAN Communication
> >          Channel (Physical)
> >                  |     ------------------------
> > ------------     v     |           :+ Control |  \
> > >          |-----------|           :+ Data    |  |
> > >    AP    |           | WWAN unit :+ Voice   |   > Functions
> > >          |===========|           :+ GPS     |  |
> > 
> > ------------     ^     |           :+ ...     |  /
> >                  |     -------------------------
> >           Multiplexed WWAN
> >            Communication
> >          Channel (Physical)

Sounds right to me. I'm not sure if you're distinguishing here between
the "Data function" and multiple data channels to the data function, but
at this point I guess it doesn't matter.

> > - The *AP* is the main CPU complex that's running Linux on one or
> >   more CPU cores.
> > - A *WWAN unit* is an entity that shares one or more physical
> >   *WWAN communication channels* with the AP.
> > - A *WWAN communication channel* is a bidirectional means of
> >   carrying data between the AP and WWAN unit.
> > - A WWAN communication channel carries data using a *WWAN protocol*.
> > - A WWAN unit implements one or more *WWAN functions*, such as
> >   5G data, LTE voice, GPS, and so on.
> > - A WWAN unit shall implement a *WWAN control function*, used to
> >   manage the use of other WWAN functions, as well as the WWAN unit
> >   itself.

I think here we need to be more careful. I don't know how you want to
call it, but we actually have multiple levels of control here.

You have
 * hardware control, to control how you actually use the (multiple or
   not) physical communication channel(s) to the WWAN unit
 * this is partially exposed to userspace via the WWAN netlink family or
   something like that, so userspace can create new netdevs to tx/rx
   with the "data function" and to the network; note that it could be
   one or multiple
 * WWAN control, which is typically userspace communicating with the
   WWAN control function in the WWAN unit, but this can take different
   forms (as I mentioned earlier, e.g. AT commands, MBIM, QMI)

> > - The AP communicates with a WWAN function using a WWAN protocol.

Right, that's just device specific (IPA vs. Intel vs. ...)

> > - A WWAN physical channel can be *multiplexed*, in which case it
> >   carries the data for one or more *WWAN logical channels*.

This ... depends a bit on how you exactly define a physical channel
here. Is that, to you, the PCIe/USB link? In that case, yes, obviously
you have only one physical channel for each WWAN unit.

However, I'd probably see this slightly differently, because e.g. the
Intel modem has multiple DMA engines, and so you actually have multiple
DMA rings to talk to the WWAN unit, and I'd have called each DMA ring a
physical channel. And then, you just have a 1:1 from physical to logical
channel since it doesn't actually carry a multiplexing protocol.

> > - A multiplexed WWAN communication channel uses a *WWAN wultiplexing
> >   protocol*, which is used to separate independent data streams
> >   carrying other WWAN protocols.

Like just described, this isn't really needed and is a device-specific
property.

> > - A WWAN logical channel carries a bidirectional stream of WWAN
> >   protocol data between an entity on the AP and a WWAN function.
> > 
> > Does that adequately represent a very high-level picture of what
> > we're trying to manage?

Pretty much.

I only disagree slightly on the control planes (there are multiple, and
multiple options for the "Control function" one), and on the whole
notion of physical link/logical link/multiplexing which is device
specific.

> > And if I understand it right, the purpose of the generic framework
> > being discussed is to define a common mechanism for managing (i.e.,
> > discovering, creating, destroying, querying, configuring, enabling,
> > disabling, etc.) WWAN units and the functions they implement, along
> > with the communication and logical channels used to communicate with
> > them.

Well, some subset of that matrix, the framework won't actually destroy
WWAN units I hope ;-)

But yes. I'd probably captured it in layers, and say that we have a

WWAN framework layer
 - discover, query, configure WWAN units
 - enable, disable channels to the functions inside the WWAN units

WWAN device driver
 - implement (partial) API offered by WWAN framework layer to allow
   these things
   (sometimes may not allow creating more control or data channels for
   example, and fixed function channels are precreated, but then can
   still discover data about the device and configure the channels
 - implement the device-specific protocols etc. necessary to achieve
   this

Userspace
 - uses control function channel (e.g. TTY) to talk directly to the WWAN
   unit's control function
 - uses WWAN framework APIs to create/configure/... (other) function
   channels
   (it may be necessary to create a control channel even, before being
   able to use it, since different options (AT/MBIM/QMI) may be there
 - configures netdevs (data function channels) after their creation

johannes


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel