Thread (59 messages) 59 messages, 9 authors, 2019-07-03

Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver

From: Dan Williams <hidden>
Date: 2019-06-04 21:29:34
Also in: linux-arm-kernel, linux-arm-msm, linux-devicetree, lkml

On Tue, 2019-06-04 at 22:04 +0200, Arnd Bergmann wrote:
On Tue, Jun 4, 2019 at 5:18 PM Dan Williams [off-list ref] wrote:
quoted
On Tue, 2019-06-04 at 10:13 +0200, Arnd Bergmann wrote:
quoted
Can you describe what kind of multiplexing is actually going on?
I'm still unclear about what we actually use multiple logical
interfaces for here, and how they relate to one another.
Each logical interface represents a different "connection" (PDP/EPS
context) to the provider network with a distinct IP address and
QoS.
VLANs may be a suitable analogy but here they are L3+QoS.

In realistic example the main interface (say rmnet0) would be used
for
web browsing and have best-effort QoS. A second interface (say
rmnet1)
would be used for VOIP and have certain QoS guarantees from both
the
modem and the network itself.

QMAP can also aggregate frames for a given channel
(connection/EPS/PDP
context/rmnet interface/etc) to better support LTE speeds.
Thanks, that's a very helpful explanation!

Is it correct to say then that the concept of having those separate
connections would be required for any proper LTE modem
implementation,
but the QMAP protocol (and based on that, the rmnet implementation)
is Qualcomm specific and shared only among several generations of
modems from that one vendor?
Exactly correct.  This is what Johannes is discussing in his "cellular
modem APIs - take 2" thread about how this should all be organized at
the driver level and I think we should figure that out before we commit
to IPA-with-a-useless-netdev that requires rmnets to be created on top.
That may end up being the solution but let's have that discussion.
quoted
You mentioned the need to have a common user space interface
for configuration, and if the above is true, I agree that we should
try
to achieve that, either by ensuring rmnet is generic enough to
cover other vendors (and non-QMAP clients), or by creating a
new user level interface that IPA/rmnet can be adapted to.
I would not suggest making rmnet generic; it's pretty QMAP specific
(but QMAP is spoken by many many modems both SoC, USB stick, and PCIe
minicard).

Instead, I think what Johannes is discussing is a better approach. A
kernel WWAN framework with consistent user API that
rmnet/IPA/qmi_wwan/MBIM/QMI/serial/Sierra can all implement.

That wouldn't affect the core packet processing of IPA/rmnet but
instead:

1) when/how an rmnet device actually gets created on top of the IPA (or
qmi_wwan) device

AND (one of these two)

a) whether IPA creates a netdev on probe

OR

b) whether there is some "WWAN device" kernel object which userspace
interacts with create rmnet channels on top of IPA

Dan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help