From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: Re: dvb usb issues since kernel 4.9 Date: Tue, 9 Jan 2018 13:48:48 -0800 Message-ID: References: <20180107090336.03826df2@vento.lan> <20180108074324.3c153189@vento.lan> <20180108223109.66c91554@redhat.com> <20180108214427.GT29822@worktop.programming.kicks-ass.net> <20180108231656.3bbd1968@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Josef Griebichler , Jesper Dangaard Brouer , Peter Zijlstra , Mauro Carvalho Chehab , Alan Stern , Greg Kroah-Hartman , USB list , Rik van Riel , Paolo Abeni , Hannes Frederic Sowa , linux-kernel , netdev , Jonathan Corbet , LMML , David Miller To: Linus Torvalds Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:42690 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752812AbeAIVsv (ORCPT ); Tue, 9 Jan 2018 16:48:51 -0500 Received: by mail-wm0-f67.google.com with SMTP id b141so23207112wme.1 for ; Tue, 09 Jan 2018 13:48:51 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP Small queues heavily use TASKLET, >> so as far as I am concerned a revert would have the same effect. > > Does it actually? > > TCP ends up dropping packets outside of the window etc, so flooding a > machine with TCP packets and causing some further processing up the > stack sounds very different from the basic packet flooding thing that > happens with NET_RX_SOFTIRQ. > > Also, honestly, the kinds of people who really worry about flooding > tend to have packet filtering in the receive path etc. > > So I really think "you can use up 90% of CPU time with a UDP packet > flood from the same network" is very very very different - and > honestly not at all as important - as "you want to be able to use a > USB DVB receiver and watch/record TV". > > Because that whole "UDP packet flood from the same network" really is > something you _fundamentally_ have other mitigations for. > > I bet that whole commit was introduced because of a benchmark test, > rather than real life. No? > > In contrast, now people are complaining about real loads not working. > > Linus I said that a revert was fine, maybe I was not clear. Clearly we can not touch anything scheduler related without breaking someone workload/assumptions on how system behaved at some point. Your patch wont solve other workloads that might have been impacted by my patch, so in one year (or next week), we will have to cope with another device driver not using tasklet but still relying on immediate softirq processing. Apparently, we have to live with softirq model forever, or switch to RT kernels. Note that we have no mitigation for something that involve flood of valid packets that no firewall can drop (without dropping legitimate packets). The 'benchmark' here is not really the trigger, only a tool validating an idea/patch.