netdev - Re: [PATCH net-next 1/1] net: usb: qmi_wwan: add default rx_urb

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 12 Nov 2020 19:28:56 +0100
From:   Daniele Palmas <dnlplm@...il.com>
To:     Kristian Evensen <kristian.evensen@...il.com>
Cc:     Bjørn Mork <bjorn@...k.no>,
        Paul Gildea <paul.gildea@...il.com>,
        Carl Yin <carl.yin@...ctel.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Network Development <netdev@...r.kernel.org>,
        linux-usb <linux-usb@...r.kernel.org>
Subject: Re: [PATCH net-next 1/1] net: usb: qmi_wwan: add default rx_urb_size

Hi Kristian,

Il giorno mer 4 nov 2020 alle ore 18:01 Kristian Evensen
<kristian.evensen@...il.com> ha scritto:
>
> Hi,
>
> On Wed, Sep 9, 2020 at 11:14 AM Daniele Palmas <dnlplm@...il.com> wrote:
> >
> > Add default rx_urb_size to support QMAP download data aggregation
> > without needing additional setup steps in userspace.
> >
> > The value chosen is the current highest one seen in available modems.
> >
> > The patch has the side-effect of fixing a babble issue in raw-ip mode
> > reported by multiple users.
> >
> > Signed-off-by: Daniele Palmas <dnlplm@...il.com>
> > ---
> > Resending with mailing lists added: sorry for the noise.
> >
> > Hi Bjørn and all,
> >
> > this patch tries to address the issue reported in the following threads
> >
> > https://www.spinics.net/lists/netdev/msg635944.html
> > https://www.spinics.net/lists/linux-usb/msg198846.html
> > https://www.spinics.net/lists/linux-usb/msg198025.html
> >
> > so I'm adding the people involved, maybe you can give it a try to
> > double check if this is good for you.
> >
> > On my side, I performed tests with different QC chipsets without
> > experiencing problems.
> >
> > Thanks,
> > Daniele
>
> First of all, I am very sorry for not providing any feedback earlier.
> I applied your patch and have been running it on my devices more or
> less since it was submitted. My devices are equipped with different
> generations of modems (cat. 4, cat. 6, cat. 12, 5G NSA), and I haven't
> noticed any problems and the babble-issue is gone.

thanks for testing. Still thinking it could be better to differentiate
between raw-ip and qmap, but not yet able to find the time to perform
some tests on my own.

> Over the last
> couple of days I also finally had a chance to experiment with QMAP,
> using an SDX55-based modem (i..e,32KB datagram support). Increasing
> the datagram size to 32KB gives a nice performance boost over for
> example 16KB. When measuring using iperf3 (on the same device), the
> throughput goes from around 210 Mbit/s and to 230 Mbit/s. The CPU was
> more or less saturated during all of my experiments, so the main
> performance gain was from the increased aggregated datagram size.
>
> As a side question, and perhaps this should be a separate thread, does
> anyone have any suggestion on how to improve QMI performance further?
> The device that I used for my iperf3-tests is mt7621-based, and using
> for example an Ethernet dongle I am able to reach somere between 400
> and 500 Mbit/s over USB. The Ethernet dongle is able to make use of
> for example scatter-gather, but I would still expect at least a bit
> more using QMI.

Is the dongle driver based on usbnet? Besides the aggregated datagram
size, did you also try different datagram max numbers?

> I tried to replace the alloc()/put() in the
> qmimux_rx_fixup() function with clone() and then doing push()/pull(),
> but this resulted in a decrease in performance. I have probably
> overlooked something, but I think at least my use of the functions was
> correct. The packets looked correct when adding some debug output,
> error counters did not increase, etc., etc. The mobile network is not
> the bottleneck, on my phone I reliably get around 400 Mbit/s.
>

Sorry, I'm not expert enough to give you any good hint.

The only advice I can give you is to check if other drivers are
performing better, e.g. did you try the MBIM composition? not sure it
will make much difference, since it's based on usbnet, but could be
worth trying.

Regards,
Daniele

> BR,
> Kristian