netdev - tx_fixup cdc_ether to mimic cdc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CA+f3hu+2y4_oh0bR=w=HYo9HDFuBzD9bkSaG_67PrGVDWGdu0Q@mail.gmail.com>
Date:   Sun, 25 Aug 2019 16:17:52 +0300
From:   Roee Kashi <galacap@...il.com>
To:     netdev@...r.kernel.org
Subject: tx_fixup cdc_ether to mimic cdc_ncm tx behavior

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.