On 2020-07-22 06:00, Felix Fietkau wrote:
On 2020-07-22 14:55, Johannes Berg wrote:
On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
I'm considering testing a different approach (with mt76 initially):
- Add a mac80211 rx function that puts processed skbs into a list
instead of handing t
On 2020-07-21 10:14, Rakesh Pillai wrote:
NAPI instance gets scheduled on a CPU core on which
the IRQ was triggered. The processing of rx packets
can be CPU intensive and since NAPI cannot be moved
to a different CPU core, to get better performance,
its better to move the gist of rx packet proces
On 2020-05-13 13:14, Christophe JAILLET wrote:
If 'thermal_cooling_device_register()' fails, we must undo what has
been
allocated so far. So we must go to 'err_thermal_destroy' instead of
returning directly
In case of error in 'ath11k_thermal_register()', the previous
'thermal_cooling_device_re
On 2020-05-06 21:11, Gustavo A. R. Silva wrote:
[...]
static inline struct htt_stats_conf_item *htt_stats_conf_next_item(
@@ -1674,7 +1674,7 @@ struct htt_tx_fetch_ind {
__le16 num_resp_ids;
__le16 num_records;
struct htt_tx_fetch_record records[0];
- __le32 resp_id
On 2018-05-23 09:25, Erik Stromdahl wrote:
On 05/22/2018 11:15 PM, Niklas Cassel wrote:
[...]
Perhaps it would be possible to call ath10k_mac_tx_push_pending()
from the equivalent to ath10k_htt_txrx_compl_task(),
but from SDIO's point of view.
An equivalent for SDIO would most likely be
*ath
On 2018-05-22 14:15, Niklas Cassel wrote:
On Mon, May 21, 2018 at 04:11:38PM -0700, Rajkumar Manoharan wrote:
On 2018-05-21 13:43, Niklas Cassel wrote:
> The following problem was observed when running iperf:
[...]
Sorry for the late response. ath10k_mac_tx_push_pending is already
called
On 2018-05-21 13:43, Niklas Cassel wrote:
The following problem was observed when running iperf:
[...]
In order to avoid trying to flush the queue every time we free a frame,
only do this when there are 3 or less frames pending, and while we
actually have frames in the queue. This logic was co
