Linux rmnet (QMAP) packets aggregation in the uplink path is now available in mainline: the first tagged release with this feature is going to be v6.3-rc1.
Continue reading to understand which problem this feature solves…
The need of coalescing
Recently I wrote about an issue I met when performing throughput testing with an MDM9207 Thread-x based modem.
Basically, there were two clear problems:
- The performance in downlink were not as expected, even though the maximum modem supported datarate was not really outstanding.
- Concurrent tx and rx testing revelead a huge throughput drop in the rx path
Those were clearly symptoms of a modem issue: the device was not capable of managing high-frequency URBs, especially when the tx path was involved.
The same test executed in a Windows environment did not show the issues, so there was something done by the Windows driver that prevented the problem from happening: this thing was the aggregation of packets in the uplink path.
Ethtool for coalescing
Packets aggregation is something managed by the QMAP protocol, but both Linux drivers implementing QMAP (qmi_wwan inbox management and rmnet) had aggregation just on the rx path, not enough for working around the issues described in the previous paragraph.
So, my first take to address the issue was implementing tx packets aggregation on qmi_wwan, but the patches used sysfs for configuring the feature, something that does not look anymore good to net maintainers: a generic way, that could be used also by other drivers, was the correct way to go.
This generic way is what has been implemented by patch “ethtool: add tx aggregation parameters“, where a new set of attributes is added to the ethtool coalesce struct.
Linux rmnet or qmi_wwan?
The second challenge of the implementation was to properly choose the target: qmi_wwan or rmnet?
Some kernel developers suggested that the issue found using the modem was something related to the bus in use (USB), so qmi_wwan would have been a better fit, but the rmnet maintainer requested this feature to be implemented in the rmnet module, so that all the rmnet based setups could benefit of the uplink aggregation.
Generally speaking I would say that, though PCIe technology does not have a specific performance problem, Qualcomm modem implementations are made in a way that packets aggregation both in uplink and downlink is required for getting the best results for throughput.
Moreover, my tests performed on a SDX55 based modem through mhi_net + rmnet highlighted a performance gain when the packets aggregation on the tx path was enabled, so the request seemed valid to me. The result is patch “net: qualcomm: rmnet: add tx packets aggregation“, that had several revisions, thanks to the comment of the various netdev experts, always patient with me.
Last patch “net: qualcomm: rmnet: add ethtool support for configuring tx aggregation” was just for adding support to the new ethtool attributes in rmnet.
So, if in a controlled environment with your Qualcomm modem you are facing symptoms like fluctuating throughput, sudden throughput drops or simply inability to reach maximum downlink throughput, give this patch-set a try, maybe it could save your day.
I’m planning to add new attributes support in ethtool userspace application for this release cycle, let’see if I’m able to do that.