qmi_wwan qmap implementation had the rx packets deaggregation feature since the very first patch in mainline, but, so far, no one had focused on adding packets aggregation for uplink. This was probably because no one felt the need of this feature: after all, differently than for the rx path, the majority of the available modems worked properly in real network conditions during transmission.
qmi_wwan qmap and low-cat modems
However, recently I stumbled upon an issue when testing an LTE cat. 4 Thread-X based modem through iperf.
The modem was theoretically capable of reaching a maximum throughput of 150Mbps in download and 50Mbps in upload. Testing individually the tx path through TCP, showed no issue, with a reported throughput > 45 Mbps.
Testing individually the rx path through TCP, revealed instead some issues: besides the throughput not reaching the maximum (about 120 Mbps), there were consistent fluctuations, without any apparent reason (the download aggregation was enabled).
But the worst came when exercising both the tx and rx paths concurrently, showing an huge drop in tx throughput, as depicted in the following image:
All these problems were not experienced in Windows, so the culprit was likely to be found in the driver.
The first step for confirming this theory was comparing a Linux usbmon trace vs. a Windows usbpcap one: the only notable difference between the two was the Windows driver aggregating the tx packets, so I added tx aggregation to qmi_wwan qmap implementation and the result is patch net: usb: qmi_wwan: implement qmap uplink tx aggregation.
The implementation is based on a similar feature available in driver cdc_ncm written by Bjørn Mork: the code basically aggregates tx packets according to the settings gotten through two new sysfs files (tx_max_datagrams_mux and tx_max_size_mux). Those values are coming from the modem when enabling qmap aggregation through wda set data format qmi request. Beware: not respecting this maximum values could easily make the modem to crash.
The patch fixed all previously reported issues, as can be seen in the following picture showing concurrent rx and tx flows:
Patch in mainline?
However, it turned out that the change was not suitable for mainline, since qmi_wwan qmap implementation is now basically deprecated in favor of kernel module rmnet and sysfs files are not accepted anymore for network device configuration (whole discussion here).
Eventually I’m trying to add the same feature to rmnet, a task that is complicated by the fact that rmnet supports more than just USB modems, requiring for sure more effort on the testing side.