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>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 19 Oct 2022 15:25:01 +0200
From:   Daniele Palmas <dnlplm@...il.com>
To:     Bjørn Mork <bjorn@...k.no>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>
Cc:     linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        Daniele Palmas <dnlplm@...il.com>
Subject: [PATCH net-next 0/2] net: usb: qmi_wwan implement tx packets aggregation

Hello Bjørn and all,

this patchset implements and document tx qmap packets aggregation in qmi_wwan.

Low-cat Thread-x based modem are not capable of properly reaching the maximum
allowed throughput both in tx and rx during a bidirectional test if tx packets
aggregation is not enabled.

I verified this problem by using a MDM9207 Cat. 4 based modem (50Mbps/150Mbps
max throughput). What is actually happening is pictured at
https://drive.google.com/file/d/1xuAuDBfBEIM3Cdg2zHYQJ5tdk-JkfQn7/view?usp=sharing

When rx and tx flows are tested singularly there's no issue in tx and minor
issues in rx (a few spikes). When there are concurrent tx and rx flows, tx
throughput has an huge drop. rx a minor one, but still present.

The same scenario with tx aggregation enabled is pictured at
https://drive.google.com/file/d/1Kw8TVFLVgr31o841fRu4fuMX9DNZqJB5/view?usp=sharing
showing a regular graph.

This issue does not happen with high-cat modems (e.g. SDX20), or at least it
does not happen at the throughputs I'm able to test currently: maybe the same
could happen when moving close to the maximum rates supported by those modems.
Anyway, having the tx aggregation enabled should not hurt.

It is interesting to note that, for what I can understand, rmnet too does not
support tx aggregation.

I'm aware that rmnet should be the preferred way for qmap, but I think there's
still value in adding this feature to qmi_wwan qmap implementation since there
are in the field many users of that.

Moreover, having this in mainline could simplify backporting for those who are
using qmi_wwan qmap feature but are stuck with old kernel versions.

I'm also aware of the fact that sysfs files for configuration are not the
preferred way, but it would feel odd changing the way for configuring the driver
just for this feature, having it different from the previous knobs.

Thanks,
Daniele

Daniele Palmas (2):
  net: usb: qmi_wwan: implement qmap uplink tx aggregation
  Documentation: ABI: sysfs-class-net-qmi: document tx aggregation files

 Documentation/ABI/testing/sysfs-class-net-qmi |  28 ++
 drivers/net/usb/qmi_wwan.c                    | 242 +++++++++++++++++-
 2 files changed, 266 insertions(+), 4 deletions(-)

-- 
2.37.1

Powered by blists - more mailing lists