From: Patrick McHardy <kaber@trash•net>
To: Simon Horman <horms@verge•net.au>
Cc: e1000-devel@lists•sourceforge.net, netdev@vger•kernel.org
Subject: Re: igb bandwidth allocation configuration
Date: Thu, 10 Sep 2009 13:28:14 +0200 [thread overview]
Message-ID: <4AA8E2CE.2080707@trash.net> (raw)
In-Reply-To: <20090910081844.GA5421@verge.net.au>
Simon Horman wrote:
> Hi,
>
> I have been looking into adding support the 82586's per-PF/VF
> bandwidth allocation to the igb driver. It seems that the trickiest
> part is working out how to expose things to user-space.
>
> I was thinking along the lines of an ethtool option as follows:
>
> ethtool --bandwidth ethN LIMIT...
>
> where:
> * There is one LIMIT per PF/VF.
> The 82576 can have up to 7 VFs per PF,
> so there would be up to 8 LIMITS
> * A keyword (none?) can be used to denote that
> bandwidth allocation should be disabled for the
> corresponding VM
> * Otherwise LIMITS are in Megabits/s
>
> This may get a bit combersome if there are a lot of VFs per PF,
> perhaps a better syntax would be:
>
> ethtool --bandwidth ethN M=LIMIT...
>
> where:
> * LIMIT is as above
> * M is some key to denote which VF/PF is
> having its limit set.
>
> Internally it seems that actually the limits are applied to HW Tx queues
> rather than directly VMs. There are 16 such queues. Accordingly it might
> be useful to design an interface to set limits per-queue using ethtool.
> But this would seem to also require exposing which queues are associated
> with which PF/VF.
Just an idea since I don't know much about this stuff:
Since we now have the mq packet scheduler, which exposes the device
queues as qdisc classes, how about adding driver-specific configuration
attributes that are passed to the driver by the mq scheduler? This
would allow to configure per-queue bandwidth limits using regular TC
commands and also use those limits without VFs for any kind of traffic.
Drivers not supporting this would refuse unsupported options.
next prev parent reply other threads:[~2009-09-10 11:28 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 [this message]
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
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=4AA8E2CE.2080707@trash.net \
--to=kaber@trash$(echo .)net \
--cc=e1000-devel@lists$(echo .)sourceforge.net \
--cc=horms@verge$(echo .)net.au \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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