From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Abeni Subject: Re: [RFC PATCH 0/2] net: threadable napi poll loop Date: Wed, 11 May 2016 11:48:24 +0200 Message-ID: <1462960104.4444.37.camel@redhat.com> References: <1462890590.23934.68.camel@edumazet-glaptop3.roam.corp.google.com> <90f3db8c-c30c-b204-576a-454939ac93ce@stressinduktion.org> <94f323a9-515e-4d75-cac8-ef0214f0499e@stressinduktion.org> <1462920697.23934.113.camel@edumazet-glaptop3.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Hannes Frederic Sowa , Eric Dumazet , netdev , "David S. Miller" , Jiri Pirko , Daniel Borkmann , Alexei Starovoitov , Alexander Duyck , Tom Herbert , Peter Zijlstra , Ingo Molnar , Rik van Riel , LKML To: Eric Dumazet Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44974 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751348AbcEKJs3 (ORCPT ); Wed, 11 May 2016 05:48:29 -0400 In-Reply-To: <1462920697.23934.113.camel@edumazet-glaptop3.roam.corp.google.com> Sender: netdev-owner@vger.kernel.org List-ID: Hi Eric, On Tue, 2016-05-10 at 15:51 -0700, Eric Dumazet wrote: > On Wed, 2016-05-11 at 00:32 +0200, Hannes Frederic Sowa wrote: > > > Not only did we want to present this solely as a bugfix but also as as > > performance enhancements in case of virtio (as you can see in the cover > > letter). Given that a long time ago there was a tendency to remove > > softirqs completely, we thought it might be very interesting, that a > > threaded napi in general seems to be absolutely viable nowadays and > > might offer new features. > > Well, you did not fix the bug, you worked around by adding yet another > layer, with another sysctl that admins or programs have to manage. > > If you have a special need for virtio, do not hide it behind a 'bug fix' > but add it as a features request. > > This ksoftirqd issue is real and a fix looks very reasonable. > > Please try this patch, as I had very good success with it. Thank you for your time and your effort. I tested your patch on the bare metal "single core" scenario, disabling the unneeded cores with: CPUS=`nproc` for I in `seq 1 $CPUS`; do echo 0 > /sys/devices/system/node/node0/cpu$I/online; done And I got a: [ 86.925249] Broke affinity for irq for each irq number generated by a network device. In this scenario, your patch solves the ksoftirqd issue, performing comparable to the napi threaded patches (with a negative delta in the noise range) and introducing a minor regression with a single flow, in the noise range (3%). As said in a previous mail, we actually experimented something similar, but it felt quite hackish. AFAICS this patch adds three more tests in the fast path and affect all other softirq use case. I'm not sure how to check for regression there. The napi thread patches are actually a new feature, that also fixes the ksoftirqd issue: hunting the ksoftirqd issue has been the initial trigger for this work. I'm sorry for not being clear enough in the cover letter. The napi thread patches offer additional benefits, i.e. an additional relevant gain in the described test scenario, and do not impact on other subsystems/kernel entities. I still think they are worthy, and I bet you would disagree, but could you please articulate more which parts concern you most and/or are more bloated ? Thank you, Paolo