Hi, I ported from Intel based modem chipset (cdc_ncm) to a Qualcomm's one (cdc_ether), and encountered a major difference between the two.
cdc_ncm had a nice "feature" (which probably wasn't the original purpose): when trying to transmit more than the module's capacity, tx_fixup would return NULL skb, hence fd buffer would remain full, causing sendto/select to block until modem is available. It's quite useful when sending UDP datagrams through an LTE link for example, since the module provides a dynamic and reliable information in real-time regarding its *incapability* of sending the datagram. For example: If my LTE link max upload bandwidth is 30Mbps, and i'll try with cdc_ncm to transmit above that, the send/select would block until modem is available, so the actual bandwidth would be 30Mbps with ~0% packet loss. with cdc_ncm: `iperf -u -c xxx -b 60Mbps` would report a TX bandwidth ~30Mbps with ~0% loss. with cdc_ether, even though the modem is unable to transmit the packet, nothing holds the tx flow: select continue and return fd as available for tx, even though the modem's buffer is full. with cdc_ether: `iperf -u -c xxx -b 60Mbps` would report a TX bandwidth ~60Mbps with ~50% loss. the difference between cdc_ncm and cdc_ether for this matter, is the 'cdc_ncm_tx_fixup' in cdc_ncm, documented as: /* * The Ethernet API we are using does not support transmitting * multiple Ethernet frames in a single call. This driver will * accumulate multiple Ethernet frames and send out a larger * USB frame when the USB buffer is full or when a single jiffies * timeout happens. */ This fixup adds this useful side-effect to cdc_ncm, and I wonder how to extend this specific behavior to cdc_ether as well, per flag. What exactly in cdc_ncm: cdc_ncm_fill_tx_frame, causing this behavior, and what is the community approach about adopting the described cdc_ncm behavior? (qmi_wwan behaves the same as cdc_ether) Cheers, Roee.
