From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francois Romieu Subject: Re: [PATCH v2 net] r8169: fix NAPI handling under high load Date: Fri, 19 Oct 2018 23:56:14 +0200 Message-ID: <20181019215614.GA14941@electric-eye.fr.zoreil.com> References: <8d75498e-6f43-a699-3a0a-fb4a2b5dc860@gmail.com> <05eb4233-bf98-4aeb-73f6-94fec46ca3de@gmail.com> <20181018225900.GA16653@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Heiner Kallweit , David Miller , Realtek linux nic maintainers , "netdev@vger.kernel.org" To: Eric Dumazet Return-path: Received: from violet.fr.zoreil.com ([92.243.8.30]:52127 "EHLO violet.fr.zoreil.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726604AbeJTGEU (ORCPT ); Sat, 20 Oct 2018 02:04:20 -0400 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Eric Dumazet : > On 10/18/2018 03:59 PM, Francois Romieu wrote: > > Eric Dumazet : > > [...] > >> One has to wonder why rtl8169_poll(), which might be called in a loop under DOS, > >> has to call rtl_ack_events() ? > > > > So as to cover a wider temporal range before any event can trigger an > > extra irq. I was more worried about irq cost than about IO cost (and > > I still am). > > > Normally the IRQ would not be enabled under DOS. Yes. My concern was not the DOS situation when NAPI runs at full speed. As far as I was able to experiment with it, the driver did not seem too bad here. The location of the ack targets the interim situation where the IRQ rate can increase before NAPI kicks in. By increasing the time range whose events can be acked, the maximum irq rate should be lowered. -- Ueimor