[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1394385809.2861.168.camel@deadeye.wl.decadent.org.uk>
Date: Sun, 09 Mar 2014 17:23:29 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: Sucheta Chakraborty <sucheta.chakraborty@...gic.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
Dept-HSGLinuxNICDev@...gic.com
Subject: Re: [RFC 1/2] net: Add support to configure SR-IOV VF minimum and
maximum Tx rate through ip tool.
On Wed, 2014-03-05 at 02:33 -0500, Sucheta Chakraborty wrote:
> o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
> which takes 4 arguments:
> netdev, VF number, min_tx_rate, max_tx_rate
>
> o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
> to have a bandwidth of at least this value.
> max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
> of up to this value.
Supposing I only want to set a minimum, how would I specify that there
is no maximum?
> o Idea is to deprecate IFLA_VF_TX_RATE and ndo_set_vf_tx_rate in future.
> And to have consistent display of rate values to user.
[...]
You can't deprecate the userland interface, but the driver operation
should be replaced at the same time.
- The rtnetlink core should combine userland settings from
IFLA_VF_TX_RATE and IFLA_VF_RATE. If both are specified, I think
IFLA_VF_RATE should override.
- If only IFLA_VF_TX_RATE is specified, the core should get the current
minimum before calling ndo_set_vf_rate.
- Drivers that currently implement ndo_set_vf_tx_rate should be
converted to implement ndo_set_vf_rate and reject attempts to set a
minimum bandwidth greater than 0.
Ben.
--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists