All of lore.kernel.org
 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: Wed, 16 Sep 2009 08:53:48 -0700	[thread overview]
Message-ID: <4AB10A0C.5010703@intel.com> (raw)
In-Reply-To: <4AB0F1BD.4020206@voltaire.com>

Or Gerlitz wrote:
> Alexander Duyck wrote:
>> 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.
> Yes, you can say that out of the per VF <mac, vlan-id, priority, rate> 
> tuple I mentioned, except for the mac, the other parameters actually 
> belong to the egress flow of the virtual switch port this VF is 
> connected to. So the vswitch actually signs the packet with vlan+pbits 
> and enforces the rate. Now vswitch can be software based, or hardware 
> NIC based.

Even something such as MAC address would make sense for a virtual 
ethernet switch configuration in that you could restrict unicast ingress 
traffic for the VF to a specific address much like you would do on a 
regular L2 switch.

> Now, I assume there may be NICs which will let you configure the 
> <vlan-id, priority, rate> as part of the their virtual switch config, 
> but others, e.g
> the 82576 as an example, and following our discussion, will let you do 
> that for the VF, in the VF driver which as you said may run the guest OS 
> where we can't control it...

I think you may be a bit confused.  The configuration for the VFs would 
be part of the PF via the virtual ethernet switch control.  As a result 
it is only the PF which needs to be running on the host.

Thanks,

Alex

      reply	other threads:[~2009-09-16 15:53 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
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 [this message]

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=4AB10A0C.5010703@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 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.