linux-kernel - Re: [PATCH v2] wifi: wfx: fix case where rates are out of order

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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 04 Oct 2023 15:00:49 +0200
From:   Jérôme Pouiller <jerome.pouiller@...abs.com>
To:     Kalle Valo <kvalo@...nel.org>
Cc:     linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        Felix Fietkau <nbd@....name>,
        Felipe Negrelli Wolter <felipe.negrelliwolter@...abs.com>,
        Olivier Souloumiac <olivier.souloumiac@...abs.com>,
        Alexandr Suslenko <suslenko.o@...x.systems>
Subject: Re: [PATCH v2] wifi: wfx: fix case where rates are out of order

On Wednesday 4 October 2023 14:57:19 CEST Kalle Valo wrote:
> Jérôme Pouiller <jerome.pouiller@...abs.com> writes:
> 
> > From: Felipe Negrelli Wolter <felipe.negrelliwolter@...abs.com>
> >
> > When frames are sent over the air, the device always applies the data
> > rates in descending order. The driver assumed Minstrel also provided
> > rate in descending order.
> >
> > However, in some cases, Minstrel can a choose a fallback rate greater
> > than the primary rate. In this case, the two rates was inverted, the
> > device try highest rate first and we get many retries.
> >
> > Since the device always applies rates in descending order, the
> > workaround is to drop the rate when it higher than its predecessor in
> > the rate list. Thus [ 4, 5, 3 ] becomes [ 4, 3 ].
> >
> > This patch has been tested in isolated room with a series of
> > attenuators. Here are the Minstrel statistics with 80dBm of attenuation:
> >
> >   Without the fix:
> >
> >                   best    ____________rate__________    ____statistics___    _____last____    ______sum-of________
> >     mode guard #  rate   [name   idx airtime  max_tp]  [avg(tp) avg(prob)]  [retry|suc|att]  [#success | #attempts]
> >     HT20  LGI  1       S  MCS0     0    1477     5.6       5.2      82.7       3     0 0             3   4
> >     HT20  LGI  1          MCS1     1     738    10.6       0.0       0.0       0     0 0             0   1
> >     HT20  LGI  1     D    MCS2     2     492    14.9      13.5      81.5       5     0 0             5   9
> >     HT20  LGI  1    C     MCS3     3     369    18.8      17.6      84.3       5     0 0            76   96
> >     HT20  LGI  1  A   P   MCS4     4     246    25.4      22.4      79.5       5     0 0         11268   14026
> >     HT20  LGI  1   B   S  MCS5     5     185    30.7      19.7      57.7       5     8 9          3918   9793
> >     HT20  LGI  1          MCS6     6     164    33.0       0.0       0.0       5     0 0             6   102
> >     HT20  LGI  1          MCS7     7     148    35.1       0.0       0.0       0     0 0             0   44
> >
> >   With the fix:
> >
> >                   best    ____________rate__________    ____statistics___    _____last____    ______sum-of________
> >     mode guard #  rate   [name   idx airtime  max_tp]  [avg(tp) avg(prob)]  [retry|suc|att]  [#success | #attempts]
> >     HT20  LGI  1       S  MCS0     0    1477     5.6       1.8      28.6       1     0 0             1   5
> >     HT20  LGI  1     DP   MCS1     1     738    10.6       9.7      82.6       4     0 0            14   34
> >     HT20  LGI  1          MCS2     2     492    14.9       9.2      55.4       5     0 0            52   77
> >     HT20  LGI  1   B   S  MCS3     3     369    18.8      15.6      74.9       5     1 1           417   554
> >     HT20  LGI  1  A       MCS4     4     246    25.4      16.7      59.2       5     1 1         13812   17951
> >     HT20  LGI  1    C  S  MCS5     5     185    30.7      14.0      41.0       5     1 5            57   640
> >     HT20  LGI  1          MCS6     6     164    33.0       0.0       0.0       0     0 1             0   48
> >     HT20  LGI  1       S  MCS7     7     148    35.1       0.0       0.0       0     0 0             0   36
> >
> > We can notice the device try now to send with lower rates (and high
> > success rates). At the end, we measured 20-25% better throughput with
> > this patch.
> >
> > Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
> > Tested-by: Olivier Souloumiac <olivier.souloumiac@...abs.com>
> > Tested-by: Alexandr Suslenko <suslenko.o@...x.systems>
> > Reported-by: Alexandr Suslenko <suslenko.o@...x.systems>
> > Co-developed-by: Jérôme Pouiller <jerome.pouiller@...abs.com>
> > Signed-off-by: Jérôme Pouiller <jerome.pouiller@...abs.com>
> > Signed-off-by: Felipe Negrelli Wolter <felipe.negrelliwolter@...abs.com>
> > ---
> > v2:
> >   - Fix malformed tags in commit body. (checkpatch still complains about
> >     missing Close tag, but the bug tracker is not public and I don't have
> >     the exact URL)
> 
> Just out of curiosity why does the checkpatch complain about a missing
> Close tag? I don't get it why there should be one.

I am on top of v6.6-rc3. I get:

    $ ./scripts/checkpatch.pl -g HEAD^..HEAD
    WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
    #26:
                      best    ____________rate__________    ____statistics___    _____last____    ______sum-of________

    WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report
    #57:
    Reported-by: Alexandr Suslenko <suslenko.o@...x.systems>
    Co-developed-by: Jérôme Pouiller <jerome.pouiller@...abs.com>
    [...]

-- 
Jérôme Pouiller