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: <003001d6611e$9afa0cc0$d0ee2640$@codeaurora.org>
Date:   Thu, 23 Jul 2020 23:55:06 +0530
From:   "Rakesh Pillai" <pillair@...eaurora.org>
To:     "'Rajkumar Manoharan'" <rmanohar@...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



> -----Original Message-----
> From: Rajkumar Manoharan <rmanohar@...eaurora.org>
> Sent: Wednesday, July 22, 2020 3:23 AM
> 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.

Hi Rajkumar,
In linux, the IRQs are directed to the first core which is booted.
I see that all the IRQs are getting routed to CORE0 even if its heavily
loaded.

IRQ and NAPI are not under the scheduler's control, since it cannot be
moved.
NAPI is scheduled only on the same core as IRQ. But a thread can be moved
around by the scheduler based on the CPU load.
This is the reason I went ahead with using thread.

Affinity settings are static, and cannot be done runtime without any
downstream userspace entity.


> 
> -Rajkumar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ