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 interfacefor 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