From: Keller, Jacob E <jacob.e.keller@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH] fm10k: Update ITR scaling mechanism based on PCIe link speed
Date: Thu, 30 Apr 2015 20:52:07 +0000 [thread overview]
Message-ID: <1430427126.25212.6.camel@intel.com> (raw)
In-Reply-To: <55419187.9040900@redhat.com>
On Wed, 2015-04-29 at 19:20 -0700, Alexander Duyck wrote:
>
> On 04/29/2015 05:10 PM, Jacob Keller wrote:
> > Red Rock Canyon's interrupt throttle timers are based on the PCIe link
> > speed. Because of this, the value being programmed into the ITR
> > registers must be scaled.
> >
> > For the PF, this is as simple as reading the PCIe link speed and storing
> > the result. However, in the case of SR-IOV, the VF's interrupt throttle
> > timers are based on the link speed of the PF. However, the VF is unable
> > to get the link speed information from its configuration space, so the
> > PF must inform it of what scale to use.
> >
> > Rather than pass this scale via mailbox message, take advantage of
> > unused bits in the TDLEN register to pass the scale. It is the
> > responsibility of the PF to program this for the VF while setting up the
> > VF queues and the responsibility of the VF to get the information
> > accordingly. This is preferable because it allows the VF to set up the
> > interrupts properly during initialization and matches how the MAC
> > address is passed in the TDBAL/TDBAH registers.
> >
> > These changes also resolve an issue with the existing ITR scale being
> > too restrictive. It would throttle down to 1300ints/s at 1538 byte
> > frames. This patch modifies the algorithm to allow for a higher range of
> > interrupts per second, from roughly 25000int/s up to 100000int/s
> > depending on our detection of the workload.
> >
> > This patch fixes a single receiving TCP_STREAM in netperf:
> > - Before: 450 Mbps
> > - After: 20,000 Mbps
> >
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > Discovered-by: Matthew Vick <matthew.vick@intel.com>
>
> Should probably be Reported-by, since I don't think Discovered-by is a
> standard convention.
>
> Also I don't think I see any of the changes I suggested. It seems like
> this could still divide the interrupt throttle rate all the way down to 0.
I'm going to defer this for a bit then, since it depends on other
changes I wasn't aware of.. Matthew?
Regards,
Jake
next prev parent reply other threads:[~2015-04-30 20:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 0:10 [Intel-wired-lan] [PATCH] fm10k: Update ITR scaling mechanism based on PCIe link speed Jacob Keller
2015-04-30 2:20 ` Alexander Duyck
2015-04-30 20:52 ` Keller, Jacob E [this message]
2015-05-01 18:17 ` Vick, Matthew
2015-04-30 12:07 ` Jeff Kirsher
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=1430427126.25212.6.camel@intel.com \
--to=jacob.e.keller@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.