From: "Leonid Grossman" <leonid.grossman@s2io.com>
To: <hadi@cyberus.ca>
Cc: <netdev@oss.sgi.com>
Subject: RE: FW: Submission for S2io 10GbE driver
Date: Sat, 24 Jan 2004 12:04:51 -0800 [thread overview]
Message-ID: <002501c3e2b5$543c45e0$0400a8c0@S2IOtech.com> (raw)
In-Reply-To: <1074967227.1732.15.camel@jzny.localdomain>
> -----Original Message-----
> From: jamal [mailto:hadi@cyberus.ca]
> Sent: Saturday, January 24, 2004 10:00 AM
> To: Leonid Grossman
> Cc: netdev@oss.sgi.com
> Subject: RE: FW: Submission for S2io 10GbE driver
>
>
> On Sat, 2004-01-24 at 00:10, Leonid Grossman wrote:
>
> > > - Adaptive Interrupt Coalescence
> >
> > There are several interrupt schemes, in the utilization scheme the
> > device can be programmed to automatically adjust interrupt
> rate based
> > upon link utilization, independently for tx and rx interrupts. For
> > instance, if the utilization is in single percentage digits
> then the
> > device can be programmed to get an interrupt per every packet since
> > interrupt rate doesn't matter much; If the utilization gets
> closer to
> > 100%, it will probably make sense to program device for, say, one
> > interrupt per 200 packets - the number will somewhat vary for
> > different systems and packet sizes.
> >
>
> How effective is this?
Today with a legacy pin iterrupts it's reasonably efective, and I have
higher hopes for MSI and MSI-X when systems and the OS starts supporting
it.
> Example you could easily fill up a link with larger packets (less
> interupts) than with smaller packets (more interupts). The
> latter overloads the system more.
> getting feedback from the system (which you can in Linux) and
> adjusting the rate that way would be more effective it seems.
These schemes could be complimentary, right now we do see that different
thresholds need to be programmed for regular and Jumbo traffic.
One thing I did not mention is that our ASIC supports several
utilization thresholds on per interrupt basis (up to 64 MSI-X
interrupts). There are also independent tx and rx queues, and each can
have it's own interrupt. There is a pretty large number of parameters
that traffic could be steered upon, packet size is one of them.
So, if you want to have different interrupt moderation schemes for
different packet sizes, you just need to steer packets to separate
queues based upon size, and then assign a separate MSI interrupt to
these queues and set different utilization thresholds for different
interrupts. At any given workload, you will be getting interrupts at
different rate for small and for big packets.
Anyway, you are right there are many interrupt moderation schemes that
host driver can deploy, our goal was to provide a flexible hardware
assist.
Thanks, Leonid
> Adjusting interupt rates based on a moving window averaging
> of the packet arrival rate would also be useful.
>
> cheers,
> jamal
>
next prev parent reply other threads:[~2004-01-24 20:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-23 21:22 FW: Submission for S2io 10GbE driver Leonid Grossman
2004-01-23 21:54 ` Stephen Hemminger
2004-01-23 21:58 ` Leonid Grossman
2004-01-23 22:22 ` FW: " Andi Kleen
2004-01-24 0:21 ` Stephen Hemminger
2004-01-27 5:32 ` Leonid Grossman
2004-01-27 6:08 ` Jeff Garzik
2004-01-27 6:19 ` Leonid Grossman
2004-02-04 20:44 ` FW: " Leonid Grossman
2004-02-05 0:49 ` Grant Grundler
2004-02-05 1:14 ` Leonid Grossman
2004-02-16 21:16 ` Leonid Grossman
2004-02-16 22:12 ` Jeff Garzik
2004-02-16 23:53 ` Leonid Grossman
2004-02-17 0:11 ` Christoph Hellwig
2004-02-17 0:16 ` Stephen Hemminger
2004-02-28 15:08 ` Submission #3 " Leonid Grossman
2004-02-28 20:21 ` Jeff Garzik
2004-03-12 21:55 ` ravinandan arakali
2004-03-13 2:30 ` Jeff Garzik
2004-03-20 4:35 ` Submission #4 " Leonid Grossman
2004-03-20 9:56 ` Jeff Garzik
2004-03-20 10:00 ` Jeff Garzik
2004-03-22 19:36 ` ravinandan arakali
2004-03-22 19:43 ` Jeff Garzik
2004-03-20 10:48 ` Christoph Hellwig
2004-02-05 1:32 ` FW: Submission " Andi Kleen
2004-02-05 1:51 ` Anton Blanchard
2004-02-05 2:46 ` Leonid Grossman
2004-02-05 3:25 ` Anton Blanchard
2004-02-05 9:27 ` Jeff Garzik
2004-02-05 9:29 ` Jeff Garzik
2004-02-05 22:09 ` Leonid Grossman
2004-02-05 22:34 ` Grant Grundler
2004-02-05 23:23 ` Jes Sorensen
2004-01-24 0:38 ` Francois Romieu
2004-01-24 3:14 ` jamal
2004-01-24 5:10 ` Leonid Grossman
2004-01-24 14:58 ` Andi Kleen
2004-01-24 17:54 ` jamal
2004-01-24 19:52 ` Leonid Grossman
2004-01-25 19:07 ` jamal
2004-01-25 17:56 ` Leonid Grossman
2004-01-24 18:00 ` jamal
2004-01-24 20:04 ` Leonid Grossman [this message]
2004-01-25 19:14 ` jamal
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='002501c3e2b5$543c45e0$0400a8c0@S2IOtech.com' \
--to=leonid.grossman@s2io.com \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).