Instantiating rmnet devices for data ports on QRTR-based modems

[Aleksander Morgado]

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?

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

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

--
Aleksander
https://aleksander.es