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
| ||
|
Message-ID: <CANn89iLXA198djT-+NGSgTqTYA=cJtcvFmcoFbY59VewrqT0BA@mail.gmail.com> Date: Tue, 28 Mar 2023 16:33:06 +0200 From: Eric Dumazet <edumazet@...gle.com> To: Jason Xing <kerneljasonxing@...il.com> Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Jason Xing <kernelxing@...cent.com> Subject: Re: [PATCH v2 net] net: rps: avoid raising a softirq on the current cpu when scheduling napi On Tue, Mar 28, 2023 at 4:21 PM Jason Xing <kerneljasonxing@...il.com> wrote: > > From: Jason Xing <kernelxing@...cent.com> > > When we are scheduling napi and then RPS decides to put the skb into > a backlog queue of another cpu, we shouldn't raise the softirq for > the current cpu. When to raise a softirq is based on whether we have > more data left to process later. But apparently, as to the current > cpu, there is no indication of more data enqueued, so we do not need > this action. After enqueuing to another cpu, net_rx_action() or > process_backlog() will call ipi and then another cpu will raise the > softirq as expected. > > Also, raising more softirqs which set the corresponding bit field > can make the IRQ mechanism think we probably need to start ksoftirqd > on the current cpu. Actually it shouldn't happen. > > Here are some codes to clarify how it can trigger ksoftirqd: > __do_softirq() > [1] net_rx_action() -> enqueue_to_backlog() -> raise an IRQ > [2] check if pending is set again -> wakeup_softirqd > > Comments on above: > [1] when RPS chooses another cpu to enqueue skb > [2] in __do_softirq() it will wait a little bit of time around 2 jiffies > > In this patch, raising an IRQ can be avoided when RPS enqueues the skb > into another backlog queue not the current one. > > I captured some data when starting one iperf3 process and found out > we can reduces around ~1500 times/sec at least calling > __raise_softirq_irqoff(). > > Fixes: 0a9627f2649a ("rps: Receive Packet Steering") No Fixes: tag, when you are trying to optimize things, and so far fail at this. > Signed-off-by: Jason Xing <kernelxing@...cent.com> > --- > v2: > 1) change the title and add more details. > 2) add one parameter to recognise whether it is napi or non-napi case > suggested by Eric. > Link: https://lore.kernel.org/lkml/20230325152417.5403-1-kerneljasonxing@gmail.com/ > --- Wrong again. I think I will send a series, instead of you trying so hard to break the stack. You have not considered busy polling, and that netif_receive_skb() contract does not enforce it to be called from net_rx_action().
Powered by blists - more mailing lists