Hi all, Il giorno sab 17 ott 2020 alle ore 23:05 Aleksander Morgado <aleksan...@aleksander.es> 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 modem. > > 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 https://patchwork.kernel.org/project/linux-arm-msm/patch/1602258664-9980-1-git-send-email-loic.poul...@linaro.org/ and https://www.spinics.net/lists/netdev/msg692557.html 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 > https://aleksander.es > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
