From: Bowers, AndrewX <andrewx.bowers@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next PATCH S10 07/10] i40e: initialize ITRN registers with correct values
Date: Mon, 23 Sep 2019 18:12:34 +0000 [thread overview]
Message-ID: <3503235df4f64fd9bd4efa8da66f3d03@intel.com> (raw)
In-Reply-To: <20190920091724.51767-7-alice.michael@intel.com>
> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Friday, September 20, 2019 2:17 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S10 07/10] i40e: initialize ITRN
> registers with correct values
>
> From: Nicholas Nunley <nicholas.d.nunley@intel.com>
>
> Since commit 92418fb14750 ("i40e/i40evf: Use usec value instead of reg value
> for ITR defines") the driver tracks the interrupt throttling intervals in single
> usec units, although the actual ITRN/ITR0 registers are programmed in 2 usec
> units. Most register programming flows in the driver correctly handle the
> conversion, although it is currently not applied when the registers are
> initialized to their default values. Most of the time this doesn't present a
> problem since the default values are usually immediately overwritten
> through the standard adaptive throttling mechanism, or updated manually by
> the user, but if adaptive throttling is disabled and the interval values are left
> alone then the incorrect value will persist.
>
> Since the intended default interval of 50 usecs (vs. 100 usecs as
> programmed) performs better for most traffic workloads, this can lead to
> performance regressions.
>
> This patch adds the correct conversion when writing the initial values to the
> ITRN registers.
>
> Signed-off-by: Nicholas Nunley <nicholas.d.nunley@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
next prev parent reply other threads:[~2019-09-23 18:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 9:17 [Intel-wired-lan] [next PATCH S10 01/10] i40e: Fix for persistent lldp support Alice Michael
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 02/10] i40e: Add ability to display VF stats along with PF core stats Alice Michael
2019-09-23 18:10 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 03/10] i40e: Wrong 'Advertised FEC modes' after set FEC to AUTO Alice Michael
2019-09-23 18:10 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 04/10] i40e: Extract detection of HW flags into a function Alice Michael
2019-09-23 18:10 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 05/10] i40e: Extend PHY access with page change flag Alice Michael
2019-09-23 18:11 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 06/10] i40e: remove the macro with it's argument reuse Alice Michael
2019-09-23 18:12 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 07/10] i40e: initialize ITRN registers with correct values Alice Michael
2019-09-23 18:12 ` Bowers, AndrewX [this message]
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 08/10] i40e: allow ethtool to report SW and FW versions in recovery mode Alice Michael
2019-09-20 19:04 ` Kwapulinski, Piotr
2019-09-23 18:13 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 09/10] i40e: Fix LED blinking flow for X710T*L devices Alice Michael
2019-09-23 18:13 ` Bowers, AndrewX
2019-09-20 9:17 ` [Intel-wired-lan] [next PATCH S10 10/10] i40e: Refactoring VF MAC filters counting to make more reliable Alice Michael
2019-09-23 18:14 ` Bowers, AndrewX
2019-09-23 18:08 ` [Intel-wired-lan] [next PATCH S10 01/10] i40e: Fix for persistent lldp support 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=3503235df4f64fd9bd4efa8da66f3d03@intel.com \
--to=andrewx.bowers@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.