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  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:   Tue, 21 Jul 2020 14:53:19 -0700
From:   Rajkumar Manoharan <rmanohar@...eaurora.org>
To:     Rakesh Pillai <pillair@...eaurora.org>
Cc:     ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvalo@...eaurora.org,
        johannes@...solutions.net, davem@...emloft.net, kuba@...nel.org,
        netdev@...r.kernel.org, dianders@...omium.org,
        evgreen@...omium.org, linux-wireless-owner@...r.kernel.org
Subject: Re: [RFC 2/7] ath10k: Add support to process rx packet in thread

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 processing
> in a high priority thread.
> 
> Add the init/deinit part for a thread to process the
> receive packets.
> 
IMHO this defeat the whole purpose of NAPI. Originally in ath10k
irq processing happened in tasklet (high priority) context which in
turn push more data to net core even though net is unable to process
driver data as both happen in different context (fast producer - slow 
consumer)
issue. Why can't CPU governor schedule the interrupts in less loaded CPU 
core?
Otherwise you can play with different RPS and affinity settings to meet 
your
requirement.

IMO introducing high priority tasklets/threads is not viable solution.

-Rajkumar

Powered by blists - more mailing lists