Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754397AbdHURRW (ORCPT ); Mon, 21 Aug 2017 13:17:22 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34221 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754356AbdHURRS (ORCPT ); Mon, 21 Aug 2017 13:17:18 -0400 Date: Mon, 21 Aug 2017 10:17:15 -0700 From: Benjamin Poirier To: "Neftin, Sasha" , Jeff Kirsher Cc: Lennart Sorensen , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] e1000e: Avoid receiver overrun interrupt bursts Message-ID: <20170821171715.iutchfoz3ksutcvw@f1.synalogic.ca> References: <20170721160937.GA22632@csclub.uwaterloo.ca> <20170721183627.13373-1-bpoirier@suse.com> <20170721183627.13373-5-bpoirier@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170721183627.13373-5-bpoirier@suse.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1503 Lines: 28 On 2017/07/21 11:36, Benjamin Poirier wrote: > When e1000e_poll() is not fast enough to keep up with incoming traffic, the > adapter (when operating in msix mode) raises the Other interrupt to signal > Receiver Overrun. > > This is a double problem because 1) at the moment e1000_msix_other() > assumes that it is only called in case of Link Status Change and 2) if the > condition persists, the interrupt is repeatedly raised again in quick > succession. > > Ideally we would configure the Other interrupt to not be raised in case of > receiver overrun but this doesn't seem possible on this adapter. Instead, > we handle the first part of the problem by reverting to the practice of > reading ICR in the other interrupt handler, like before commit 16ecba59bc33 > ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit > 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME > from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts > anymore. We handle the second part of the problem by not re-enabling the > Other interrupt right away when there is overrun. Instead, we wait until > traffic subsides, napi polling mode is exited and interrupts are > re-enabled. > > Reported-by: Lennart Sorensen > Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt") > Signed-off-by: Benjamin Poirier What's the status on these patches please? One month later they still show up as "new" in patchwork.