From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Simon Horman <horms@verge.net.au>
Cc: "e1000-devel@lists.sourceforge.net"
<e1000-devel@lists.sourceforge.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
Arnd Bergmann <arndbergmann@googlemail.com>
Subject: Re: [rfc 4/4] igb: expose 82576 bandiwidth allocation
Date: Thu, 05 Nov 2009 15:00:02 -0800 [thread overview]
Message-ID: <4AF358F2.9000109@intel.com> (raw)
In-Reply-To: <20091105010628.148945886@vergenet.net>
Simon Horman wrote:
> The 82576 has support for bandwidth allocation to VFs.
>
> Contrary to the documentation in the 82576 datasheet v2.41 this
> appears to work as follows:
>
> * The ratio supplied is always proportional to 1Gbit/s,
> regardless of if the link speed.
> * The ratio supplied is an upper-bound on bandwidth available
> to the VF, not a minimun guarantee
>
> This patch exposes bandwidth control to userspace through a simple
> per-device (PF) sysfs file, bandwidth_allocation.
>
> * The file contains a whitespace delimited list of values, one per VF.
> * The first value corresponds to the first VF and so on.
> * Valid values are integers from 0 to 1000
> * A value of 0 indicates that bandwidth_allocation is disabled.
> * Other values indicate the allocated bandwidth, in 1/1000ths of a gigabit/s
>
> e.g. The following for a PF with 4 VFs allocates ~20Mbits/ to VF 1,
> ~100Mbit/s to VF 2, and leave the other 2 VFs with no allocation.
>
> echo "20 100 0 0" > /sys/class/net/eth3/device/bandwidth_allocation
>
> This interface is intended to allow testing of the hardware feature.
> There are ongoing discussions about how to expose this feature
> to user-space in a more generic way.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
Of the patches it looks like the only one that really has any issues is
this one and it is mostly due to the sysfs implementation. The others I
would say can be applied and pushed up into the net-next-2.6 tree.
We're currently working on an iproute2 based solution for configuring
VFs and can incorporate this functionality into it at some point in the
future.
Thanks,
Alex
next prev parent reply other threads:[~2009-11-05 22:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 0:58 [rfc 0/4] igb: bandwidth allocation Simon Horman
2009-11-05 0:58 ` [rfc 1/4] igb: Add igb_cleanup_vf() Simon Horman
2009-11-05 0:58 ` [rfc 2/4] igb: Initialise adapter->vfs_allocated_count in igb_init_vf() Simon Horman
2009-11-05 0:58 ` [rfc 3/4] igb: Common error path in igb_init_vfs() Simon Horman
2009-11-05 0:58 ` [rfc 4/4] igb: expose 82576 bandiwidth allocation Simon Horman
2009-11-05 23:00 ` Alexander Duyck [this message]
2009-11-05 23:30 ` Simon Horman
2009-11-05 23:42 ` Alexander Duyck
2009-11-06 3:57 ` Simon Horman
2009-11-05 1:46 ` [rfc 0/4] igb: bandwidth allocation Jeff Kirsher
2009-11-05 2:21 ` Simon Horman
2009-11-14 8:01 ` Jeff Kirsher
2009-11-25 6:31 ` Simon Horman
2009-11-05 12:09 ` Andi Kleen
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=4AF358F2.9000109@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=arndbergmann@googlemail.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=horms@verge.net.au \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.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 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).