[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1395966365.2898.18.camel@deadeye.wl.decadent.org.uk>
Date: Fri, 28 Mar 2014 00:26:05 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: Sucheta Chakraborty <sucheta.chakraborty@...gic.com>,
netdev@...r.kernel.org, Dept-HSGLinuxNICDev@...gic.com,
gregory.v.rose@...el.com, linux-net-drivers@...arflare.com,
Ariel.Elior@...gic.com, amirv@...lanox.com
Subject: Re: [RFC v2 1/1] net: Add support to configure SR-IOV VF minimum
and maximum Tx rate through ip tool.
On Wed, 2014-03-26 at 08:37 +0100, Michal Kubecek wrote:
> On Monday 24 of March 2014 18:55:00 Ben Hutchings wrote:
> >
> > Also, this special-casing of -1 isn't documented anywhere. Is it even
> > necessary? If userland needs to set just one limit, it can read the
> > existing limits and set both.
>
> Wouldn't this open a window for a race if one process wanted to change
> one limit and another process wanted to change the other at the same
> time? Such scenario doesn't sound very realistic but our customers
> taught me that things I don't find very realistic tend to be used quite
> frequently by them.
If there are two processes trying to change the minimum and maximum
bandwidth of a VF at the same time, something has gone wrong already.
This is a problem for userland to solve.
Ben.
> On the other hand, if changing only one limit is going to be common, it
> might be more appropriate to add IFLA_VF_TX_MIN_RATE instead and always
> pass the minimum and maximum rate separately (and pass only one if only
> one is going to be changed).
--
Ben Hutchings
73.46% of all statistics are made up.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists