Received: by 10.223.176.5 with SMTP id f5csp3024007wra; Mon, 29 Jan 2018 07:43:40 -0800 (PST) X-Google-Smtp-Source: AH8x224vc69cxPLynBnCsX0B0q80vLjJ2bLDFMTKMtfZaPOYMYy+TrmZZOpzJ5JfPDwVZJ3u8fUh X-Received: by 2002:a17:902:102:: with SMTP id 2-v6mr22278999plb.178.1517240620180; Mon, 29 Jan 2018 07:43:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517240620; cv=none; d=google.com; s=arc-20160816; b=JE/FaMrqyefJ9rWru9JiFRteGP/25gbOqXTFkl41L8F5GwHVckCpU3I7EPY+NG9ehd URX1JgmB9oWCXyi8kIIPwgEcOjCbkvis0KT/WtbiQE0q48kiSKVTGqg1reMDXbsJQ+OJ ejYiuQTp5NFhX0NaWGGNh1i+44oIQqbbbNA0ThLm7MZ+mDV32UoP2KlzctwX9utm1ipu Zy2G0rZ+DByx25JS6zNXX1C/CJkLDmp3QAoULgFA7Kl3QbvFn9tbBblb9ZyWEXbo+Eld DhtggYIQ2pIweA3kV52KY52XjhP70r/pRjv/48chhfAs5n9dg/a9mP/Gf7lg93vGgmd/ WPsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=U5yZrPEiUjGOE4AYIoxDM/Cd3pyCU4igJ6r4lDrvCJY=; b=kI1wCvYRIAtBxiAb3kjsr4s4Iv+F9JNO3wsgA/djgL9abzGKe+5MmBXn9SxIDj/RI+ KhE/MxIdU+pgZveb/u5lpRB3ZSsyXis0MFdmJCzoYKKUpXVnHg8/+S4c/VzT3Qt+XWjA FRk6Yc43iBX3Jj2Y6g6zpaJeqDt8zwDpsB5+2G+tv2irXIdEnApfjdLvdb4Qi/Q86Jcj zJONvVfgzimvl3zJOtWNHzQtIcwJqrxanZGBGP1quxdMV0MX/CKU9Gbfy8Kaf2DwQu0J eGIT7QzSJY8CtscUPNIEyMsc2uD5+kT0B7JMNxIteum/IblCIf4uessNDW/mkJZjJVWO 1YZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KBasLdcO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o30si7594582pgn.548.2018.01.29.07.43.24; Mon, 29 Jan 2018 07:43:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KBasLdcO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751839AbeA2PnA (ORCPT + 99 others); Mon, 29 Jan 2018 10:43:00 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:45415 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbeA2Pm6 (ORCPT ); Mon, 29 Jan 2018 10:42:58 -0500 Received: by mail-qt0-f194.google.com with SMTP id x27so13162148qtm.12; Mon, 29 Jan 2018 07:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U5yZrPEiUjGOE4AYIoxDM/Cd3pyCU4igJ6r4lDrvCJY=; b=KBasLdcOjW4DiiXf0SzDI/TPZN6y2jQE938I6vukLcSHbNBUyO5G7ej0xSWq+zZnYo 69nKn+nlaQDHd/vnHap44lsPL+HBSUIU+Xjjx5gsGUbrskEEZvcvCTHcAlj2CPCUyWKE y+9D4pnb1kEOu1O6nwYec2ZRODGPGiGVAsJhQ15dEpOTQZ5YqXzuL550nJpwyGcpwEOR IaoO/9gIhrd2Y9QcWPcDPpxi3GFB9CvnBnPITj7Wcy/eLPlBhyQr8Scu8mGMCXGnIDbr YFztq5r1zcX/1WxOHsvl0kwHfZ7IzYxHibmbCdBDbX1J0HlfM7vavuKWm+92xfgGPdIu tLqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U5yZrPEiUjGOE4AYIoxDM/Cd3pyCU4igJ6r4lDrvCJY=; b=XzPHxlaB1Yk/BuvjfI3PLJfaBi2jXtMzI6rR1gBReup8gzpdsklMj4KO5RigrCWz1k CKs3EoAMPQKgeqcXxyeBqRKYO6x+jJPmtQwEubMf4/mvMLHWx6ObCPQzIMuapYqq93oR Hpz5pOyHCOcjpeSjpX0tZ+Oar5p48yHzpwN4eQGDE9pCCwJ9wOIFdoy4YdRBM0Zlr40J KOUttxBnErF6iYLb2/Z9Vr33s44CkzWTXbbzy1UanG2451oFpslBiih4OwMDLLyu+cZH VggZXahTPy96FUir60Rx7lMHkmgE1/utbcDddfOjeJZeHyGAJnzTdQ4zknAKdW+ngchi 27SA== X-Gm-Message-State: AKwxytdavPBqzqmw73zV0qfARuXNLtj1WGm5XG8sxB3sBtbZi4LHM9aj PiLo3oEx+7Dt6EcQYa/bnpjShSdRtz0DkRo77VDI+2TS X-Received: by 10.237.42.198 with SMTP id t64mr39437829qtd.177.1517240576955; Mon, 29 Jan 2018 07:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.199 with HTTP; Mon, 29 Jan 2018 07:42:56 -0800 (PST) In-Reply-To: <20180129072036.jninnfmjzcxnpput@f1.synalogic.ca> References: <20180126091236.13044-1-bpoirier@suse.com> <20180126091236.13044-2-bpoirier@suse.com> <20180129072036.jninnfmjzcxnpput@f1.synalogic.ca> From: Alexander Duyck Date: Mon, 29 Jan 2018 07:42:56 -0800 Message-ID: Subject: Re: [PATCH 1/3] Partial revert "e1000e: Avoid receiver overrun interrupt bursts" To: Benjamin Poirier Cc: Jeff Kirsher , intel-wired-lan , Netdev , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 28, 2018 at 11:20 PM, Benjamin Poirier wrote: > On 2018/01/26 08:50, Alexander Duyck wrote: >> On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier wrote: >> > This reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d. >> > >> > We keep the fix for the first part of the problem (1) described in the log >> > of that commit however we use the implementation of e1000_msix_other() from >> > before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). >> > We remove the fix for the second part of the problem (2). >> > >> > Bursts of "Other" interrupts may once again occur during rxo (receive >> > overflow) traffic conditions. This is deemed acceptable in the interest of >> > reverting driver code back to its previous state. The e1000e driver should >> > be in "maintenance" mode and we want to avoid unforeseen fallout from >> > changes that are not strictly necessary. >> > >> > Link: https://www.spinics.net/lists/netdev/msg480675.html >> > Signed-off-by: Benjamin Poirier >> >> Thanks for doing this. >> >> Only a few minor tweaks I would recommend. Otherwise it looks good. >> >> > --- >> > drivers/net/ethernet/intel/e1000e/defines.h | 1 - >> > drivers/net/ethernet/intel/e1000e/netdev.c | 32 +++++++++++------------------ >> > 2 files changed, 12 insertions(+), 21 deletions(-) >> > >> > diff --git a/drivers/net/ethernet/intel/e1000e/defines.h b/drivers/net/ethernet/intel/e1000e/defines.h >> > index afb7ebe20b24..0641c0098738 100644 >> > --- a/drivers/net/ethernet/intel/e1000e/defines.h >> > +++ b/drivers/net/ethernet/intel/e1000e/defines.h >> > @@ -398,7 +398,6 @@ >> > #define E1000_ICR_LSC 0x00000004 /* Link Status Change */ >> > #define E1000_ICR_RXSEQ 0x00000008 /* Rx sequence error */ >> > #define E1000_ICR_RXDMT0 0x00000010 /* Rx desc min. threshold (0) */ >> > -#define E1000_ICR_RXO 0x00000040 /* Receiver Overrun */ >> > #define E1000_ICR_RXT0 0x00000080 /* Rx timer intr (ring 0) */ >> > #define E1000_ICR_ECCER 0x00400000 /* Uncorrectable ECC Error */ >> > /* If this bit asserted, the driver should claim the interrupt */ >> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c >> > index 9f18d39bdc8f..398e940436f8 100644 >> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c >> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c >> > @@ -1914,30 +1914,23 @@ static irqreturn_t e1000_msix_other(int __always_unused irq, void *data) >> > struct net_device *netdev = data; >> > struct e1000_adapter *adapter = netdev_priv(netdev); >> > struct e1000_hw *hw = &adapter->hw; >> > - u32 icr; >> > - bool enable = true; >> > - >> > - icr = er32(ICR); >> > - if (icr & E1000_ICR_RXO) { >> > - ew32(ICR, E1000_ICR_RXO); >> > - enable = false; >> > - /* napi poll will re-enable Other, make sure it runs */ >> > - if (napi_schedule_prep(&adapter->napi)) { >> > - adapter->total_rx_bytes = 0; >> > - adapter->total_rx_packets = 0; >> > - __napi_schedule(&adapter->napi); >> > - } >> > - } >> > - if (icr & E1000_ICR_LSC) { >> > - ew32(ICR, E1000_ICR_LSC); >> > + u32 icr = er32(ICR); >> > + >> > + if (icr & adapter->eiac_mask) >> > + ew32(ICS, (icr & adapter->eiac_mask)); >> >> I'm not sure about this bit as it includes queue interrupts if I am >> not mistaken. What we should be focusing on are the bits that are not >> auto-cleared so this should probably be icr & ~adapter->eiac_mask. >> Actually what you might do is something like: >> icr &= ~adapter->eiac_mask; >> if (icr) >> ew32(ICS, icr); >> >> Also a comment explaining that we have to clear the bits that are not >> automatically cleared by other interrupt causes might be useful. > > I've re-read your comment many times and I think you misunderstood what > that code is doing. You are right. I did. > This: >> > + if (icr & adapter->eiac_mask) >> > + ew32(ICS, (icr & adapter->eiac_mask)); > > re-raises the queue interrupts in case the txq or rxq bits were set in > icr and the Other interrupt handler read and cleared icr before the > queue interrupt was raised. It's not about "clear the bits that are not > automatically cleared". It's a write to ICS, not ICR. Actually this raises other possible issues. Now I am wondering if the actual issue is the fact that we are reading the ICR at all in MSI-X mode with EIAME enabled. For now I guess we need it since reading the ICR could potentially be causing the events to be cleared. There is actually HW Errata 12 that we need to take into account as well, the document is available at: https://www.intel.com/content/www/us/en/embedded/products/networking/82574-gbe-controller-spec-update.html I think I may check with our Client silicon team to see if there is any way for us to get away from reading ICR and still avoid the RXO issue since it seems like reading ICR is just going to be problematic at best. If nothing else we probably need a new HW errata for the RXO problem since it seems like it is firing interrupts even though it should be masked. >> >> > + if (icr & E1000_ICR_OTHER) { >> > + if (!(icr & E1000_ICR_LSC)) >> > + goto no_link_interrupt; >> >> I wouldn't bother with the jump tag. Let's just make this one if >> statement checking both OTHER && LSC. >> >> > hw->mac.get_link_status = true; >> > /* guard against interrupt when we're going down */ >> > if (!test_bit(__E1000_DOWN, &adapter->state)) >> > mod_timer(&adapter->watchdog_timer, jiffies + 1); >> > } >> > >> > - if (enable && !test_bit(__E1000_DOWN, &adapter->state)) >> > - ew32(IMS, E1000_IMS_OTHER); >> > +no_link_interrupt: >> >> If you just combine the if statement logic the code naturally flows to >> this point anyway without the jump label being needed. > > After this patch, the implementation of e1000_msix_other() is what it > was before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other > interrupt"), verbatim. > > I agree with your comment though and the binary code is the same. > Changed for the next version. We may need to look at clearing the ICR still, or are you expecting the read auto cleared it? >> >> > + if (!test_bit(__E1000_DOWN, &adapter->state)) >> > + ew32(IMS, E1000_IMS_LSC | E1000_IMS_OTHER); >> > >> > return IRQ_HANDLED; >> > } >> > @@ -2707,8 +2700,7 @@ static int e1000e_poll(struct napi_struct *napi, int weight) >> > napi_complete_done(napi, work_done); >> > if (!test_bit(__E1000_DOWN, &adapter->state)) { >> > if (adapter->msix_entries) >> > - ew32(IMS, adapter->rx_ring->ims_val | >> > - E1000_IMS_OTHER); >> > + ew32(IMS, adapter->rx_ring->ims_val); >> > else >> > e1000_irq_enable(adapter); >> > } >> > -- >> > 2.15.1 >> > >>