All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duyck, Alexander H <alexander.h.duyck@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next PATCH S80-V3 04/11] i40e/i40evf: always set	the CLEARPBA flag when re-enabling interrupts
Date: Thu, 5 Oct 2017 18:31:56 +0000	[thread overview]
Message-ID: <1507228314.2098.53.camel@intel.com> (raw)
In-Reply-To: <26D9FDECA4FBDD4AADA65D8E2FC68A4A10EAA0C8@ORSMSX104.amr.corp.intel.com>

On Tue, 2017-09-12 at 20:46 +0000, Bowers, AndrewX wrote:
> > -----Original Message-----
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> > Behalf Of Alice Michael
> > Sent: Thursday, September 7, 2017 5:06 AM
> > To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> > lan at lists.osuosl.org
> > Subject: [Intel-wired-lan] [next PATCH S80-V3 04/11] i40e/i40evf: always set
> > the CLEARPBA flag when re-enabling interrupts
> > 
> > From: Jacob Keller <jacob.e.keller@intel.com>
> > 
> > In the past we changed driver behavior to not clear the PBA when re-
> > enabling interrupts. This change was motivated by the flawed belief that
> > clearing the PBA would cause a lost interrupt if a receive interrupt occurred
> > while interrupts were disabled.
> > 
> > According to empirical testing this isn't the case. Additionally, the data sheet
> > specifically says that we should set the CLEARPBA bit when re-enabling
> > interrupts in a polling setup.
> > 
> > This reverts commit 40d72a509862 ("i40e/i40evf: don't lose interrupts")
> > 
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > ---
> >  drivers/net/ethernet/intel/i40e/i40e.h             |  5 +----
> >  drivers/net/ethernet/intel/i40e/i40e_main.c        | 11 +++++------
> >  drivers/net/ethernet/intel/i40e/i40e_txrx.c        |  6 ++----
> >  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  2 +-
> >  drivers/net/ethernet/intel/i40evf/i40e_txrx.c      |  4 +---
> >  5 files changed, 10 insertions(+), 18 deletions(-)
> 
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> 

This patch just got pointed out to me in a hallway conversation.

I am pretty sure this _will_ cause you to lose interrupts. Specifically
you shouldn't be clearing the PBA bit at the end of the polling routine
unless you know you are going to poll again.

The PBA bit should only be cleared if:
1. You are at the start of your clean-up routine and want to clear it
in case any additional work has come in since the original vector
fired. (currently handled via an auto-clear function for MSI-X)
2. You are at the end of your polling routine and you know you are
going to be polling again.

The original patch was more aggressive than it needed to be. For
example you could probably go ahead and clear the PBA in the
i40e_intr()q interrupt routine itself since all it is doing is
scheduling the polling routine which will run after the interrupt
routine has completed. You shouldn't be clearing the PBA at the end of
NAPI poll unless you know you are not going to be exiting polling.

I hope this helps to clarify things.

- Alex

  reply	other threads:[~2017-10-05 18:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07 12:05 [Intel-wired-lan] [next PATCH S80-V3 01/11] i40e: use the safe hash table iterator when deleting mac filters Alice Michael
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 02/11] i40evf: fix mac filter removal timing issue Alice Michael
2017-09-12 20:23   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 03/11] i40e/i40evf: fix incorrect default ITR values on driver load Alice Michael
2017-09-12 20:30   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 04/11] i40e/i40evf: always set the CLEARPBA flag when re-enabling interrupts Alice Michael
2017-09-12 20:46   ` Bowers, AndrewX
2017-10-05 18:31     ` Duyck, Alexander H [this message]
2017-10-05 22:24       ` Keller, Jacob E
2017-10-05 23:01         ` Jesse Brandeburg
2017-10-05 23:25           ` Keller, Jacob E
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 05/11] i40e: reduce lrxqthresh from 2 to 1 Alice Michael
2017-09-12 21:33   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 06/11] i40e/i40evf: bump tail only in multiples of 8 Alice Michael
2017-09-12 21:40   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 07/11] i40e/i40evf: bundle more descriptors when allocating buffers Alice Michael
2017-09-12 21:41   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 08/11] i40e: allow XPS with QoS enabled Alice Michael
2017-09-12 21:47   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 09/11] i40e: add check for return from find_first_bit call Alice Michael
2017-09-12 21:48   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 10/11] i40e: Retry AQC GetPhyAbilities to overcome I2CRead hangs Alice Michael
2017-09-12 22:15   ` Bowers, AndrewX
2017-09-07 12:05 ` [Intel-wired-lan] [next PATCH S80-V3 11/11] i40e: use a local variable instead of calculating multiple times Alice Michael
2017-09-12 21:52   ` Bowers, AndrewX
2017-09-12 16:53 ` [Intel-wired-lan] [next PATCH S80-V3 01/11] i40e: use the safe hash table iterator when deleting mac filters Bowers, AndrewX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507228314.2098.53.camel@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.