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]
Message-ID: <5bb08a2db092c590119ff706ac3654de14c984fc.camel@sipsolutions.net>
Date:   Thu, 10 Jun 2021 22:18:42 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     chris.chiu@...onical.com, Jes.Sorensen@...il.com,
        kvalo@...eaurora.org, davem@...emloft.net, kuba@...nel.org
Cc:     linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] rtl8xxxu: unset the hw capability
 HAS_RATE_CONTROL

Hi Chris,

> Since AMPDU_AGGREGATION is set so packets will be handed to the
> driver with a flag indicating A-MPDU aggregation and device should
> be responsible for setting up and starting the TX aggregation with
> the AMPDU_TX_START action. The TX aggregation is usually started by
> the rate control algorithm so the HAS_RATE_CONTROL has to be unset
> for the mac80211 to start BA session by ieee80211_start_tx_ba_session.
> 
> The realtek chips tx rate will still be handled by the rate adaptive
> mechanism in the underlying firmware which is controlled by the
> rate mask H2C command in the driver. Unset HAS_RATE_CONTROL cause
> no change for the tx rate control and the TX BA session can be started
> by the mac80211 default rate control mechanism.

This seems ... strange, to say the least? You want to run the full
minstrel algorithm just to have it start aggregation sessions at the
beginning?

I really don't think this makes sense, and it's super confusing. It may
also result in things like reporting a TX rate to userspace/other
components that *minstrel* thinks is the best rate, rather than your
driver's implementation, etc.

I suggest you instead just call ieee80211_start_tx_ba_session() at some
appropriate time, maybe copying parts of the logic of
minstrel_aggr_check().

johannes


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ