Instantiating rmnet devices for data ports on QRTR-based modems

Daniele Palmas dnlplm at
Mon Oct 19 04:44:40 UTC 2020

Hi all,

Il giorno sab 17 ott 2020 alle ore 23:05 Aleksander Morgado
<aleksander at> ha scritto:
> Hey Carl,
> >         Some ideas from me.
> Thanks for your comments, very much appreciated.
> >         The discussion is based on QUALCOMM's rmnet driver and his data services.
> >         We are discussing how porting these software to MM and libqmi.
> >         But I think QUALLCOMM's solution is too complex, porting is impossible.
> >         What we have to do is re-implementation.
> >
> >         I seem we have done for "QMI based on QTRT" in libqmi.
> >         For QUALCOMM's data services, there are lots of QMI library, and libqmi used a more simply solution. (in fact, if just send QMI, QTRT is also not a good idea)
> Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only
> way to handle the communication in certain setups?
> >
> >         So, others part of QUALCOMM's data services and  QUALCOMM's rmnet drvier, we also can simplify.
> >
> I'm all for simplifying :D
> >         Take rmnet driver for example:
> >         QUALCOMM;s  rmnet driver consist of two parts.
> >         1. physic netcard part, name as rmnet_usb.c/rmnet_mhi.c/rmnet_ipa.c,, depend on the hardware interface used.
> >                 this driver response for transfer QMAP packet to modem.
> >         2. virtual nectar part, name as rmnet_data.c, this driver response for: rx IP packets from tcp/ip stack, and add QMAP header to IP packet, and sent to rmnet physic driver.
> >
> Ok, understood.
> >         So the process can next:
> >         1. rmnet physic driver probe, create netcard rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data
> >         2. rmnet data driver create rmnet_data0
> Are you suggesting that there is always a virtual network interface
> created for the physical network interface? In terms of qmi_wwan, are
> you suggesting a virtual qmimux0 is always created when the physical
> wwan0 interface is exposed? What would be the benefit of doing that?

One of the benefits is dl throughput for high-cat modems, since
enabling data aggregation is mandatory to get the most out of the

> >         3. MM query qmap-version, ep-type, iface-id, dll_data_aggregation_max_size from rmnet physic driver
> >         4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem.
> >         5. MM get ul_data_aggregation_max_size from QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver.
> @Bjørn Mork @Daniele Palmas is that step 5 something we're not
> currently doing and we may need to do? Does the physical wwan
> interface truly need to know the ul_data_aggregation_max_size?

I can't find this WDS request, or do you mean QMI_WDA_SET_DATA_FORMAT?
Anyway, the driver is not dealing with ul values: so far I did not
receive complaints on upload performance, even with high-cat modems,
so I'm not sure this is something that should be fixed at the moment.
I'm more concerned about the dl aggregation, whose setting is still a
manual process.

> >         6. MM want to setup data call on PDN-x. MM send muxid-X to rmnet physic driver, rmnet physic driver tell rmnet data driver to create rmnet_dataX.
> >
> This logic you're suggesting, except for step 5 I think, is what we
> already had in mind more or less. I think we could have that done by
> ModemManager, and connection managers like NetworkManager will get
> that working automatically, but now I also fear that if we change the
> default QMI modem behavior w.r.t. which is the connected network
> interface, we may be breaking user setups out there that rely on fixed
> interface names (e.g. for iptables rules).
> >         rmnet_dataX is not a good name, there may be rment_usb0, rment_mhi0 exist at the same time, so can named as rment_usb0_X.
> In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And
> if you have 5 different modems, each of them instantiating muxed
> virtual interfaces, they'll just get assigned sequential interface
> names, without any reference in the interface name to which physical
> interface they're mapped to. I don't think the name of the interface
> matters much at this point, as long as we can know which virtual
> interface maps to which physical interface.
> E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs
> contents pointing to the physical interface:
> # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> lrwxrwxrwx    1 root     root             0 Oct 17 20:52
> /sys/class/net/qmimux0/lower_wwan0 ->
> ../../../pci0000:00/0000:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0
> And it adds a "upper_qmimux0" file in the physical interface sysfs
> pointing to the virtual device:
> # ls -ltr /sys/class/net/wwan0/upper_qmimux0
> lrwxrwxrwx    1 root     root             0 Oct 17 20:53
> /sys/class/net/wwan0/upper_qmimux0 ->
> ../../../../../../../../virtual/net/qmimux0
> As long as we have this kind of relationship between the virtual and
> physical interfaces, we're good to go, regardless of the actual naming
> of the interface.
> It is true, though, that with the current qmi_wwan logic we cannot
> force Qualcomm's relationship between mux ID and the name of the
> interface  being ID-1, because the qmimux names are given sequentially
> as they're allocated. Not a big deal, though.

By the way, not strictly related to this thread, but there is a very
good effort ongoing for upstreaming mhi driver, mainly targeted on
SDX55, see for example

The uci driver is still missing, but I think it will be just a matter
of time: the interesting part is that with uci a char qmi device is
exposed that, according to my current tests, is behaving at the high
level just like the cdc-wdm device.

> --
> Aleksander
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at

More information about the ModemManager-devel mailing list