netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Or Gerlitz <ogerlitz@voltaire.com>
Cc: Simon Horman <horms@verge.net.au>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Subject: Re: igb bandwidth allocation configuration
Date: Tue, 15 Sep 2009 11:01:52 -0700	[thread overview]
Message-ID: <4AAFD690.5040900@intel.com> (raw)
In-Reply-To: <4AAF963D.4060708@voltaire.com>

Or Gerlitz wrote:
> If the rate limiter is exposed as a feature of the VF, it doesn't matter 
> who really enforces it, the "VF portion" of the HW or the PF itself. I 
> agree that if you have to program the PF for the rate of a specific VF, 
> then its more complex. Basically, I would expect that a VF can be 
> configured with <mac, vlad-id, priority, rate> such that it can be done 
> where the VF NIC is spawned, host kernel or guest kernel.

Adding the rate limiter as a feature of the VF doesn't make much sense 
since the VF could be direct assigned to another OS for all we know so 
we won't have control over it from there.

The interface for all of this would make sense as part of a virtual 
ethernet switch control which is the way I am currently leaning on all 
this.  As such it is probably another thing we can bring up at the BOF 
session at the Linux Plumbers Conference.

> I'm was asking/wondering if the Intel NICs have a rate limiter (i.e one 
> can program the VF such that its rate doesn't exceed XX MB/s) or a "rate 
> guarantee"  (i.e one can program the VF such that its guaranteed it will 
> get YY MB/s in case it wants to xmit at least this bandwidth)

Based on the way I am reading the documentation I would say the all 
these registers do is guarantee a minimum percentage of the bandwidth. 
With these registers set you can repartition the traffic so that a 
percentage can be guaranteed to the PF/VFs if needed.  It works very 
similar to how DCB allows you to guarantee a certain amount of bandwidth 
for each of the traffic classes.  However any time the full tx bandwidth 
is not being used it will be reallocated to the other queues and then 
end up back in the default behavior.

The default behavior is to DMA descriptors from the rings in a round 
robin fashion.  Since this effectively guarantees that there will be 
packets being pulled off the rings I didn't really feel the necessity to 
add the additional overhead of doing this on a per PF/VF bandwidth basis.

Thanks,

Alex

  reply	other threads:[~2009-09-15 18:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-10  8:18 igb bandwidth allocation configuration Simon Horman
2009-09-10 11:28 ` Patrick McHardy
2009-09-10 11:55   ` Patrick McHardy
2009-09-11  0:38     ` Simon Horman
2009-09-15 11:32       ` Simon Horman
2009-09-14  8:42 ` Or Gerlitz
2009-09-15 11:36   ` Simon Horman
2009-09-15 13:27     ` Or Gerlitz
2009-09-15 18:01       ` Alexander Duyck [this message]
2009-09-15 18:25         ` Nelson, Shannon
2009-09-15 22:29         ` Simon Horman
2009-09-16  6:47           ` Or Gerlitz
2009-09-16  7:04             ` Simon Horman
2009-09-16 16:10               ` Nelson, Shannon
2009-09-17  1:09           ` Simon Horman
2009-09-16 14:10         ` Or Gerlitz
2009-09-16 15:53           ` Alexander Duyck

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=4AAFD690.5040900@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=alexander.duyck@gmail.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=horms@verge.net.au \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@voltaire.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).