netdev - Re: igb bandwidth allocation configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AAFD690.5040900@intel.com>
Date:	Tue, 15 Sep 2009 11:01:52 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Or Gerlitz <ogerlitz@...taire.com>
CC:	Simon Horman <horms@...ge.net.au>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Alexander Duyck <alexander.duyck@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: Re: igb bandwidth allocation configuration

Or Gerlitz wrote:
> If the rate limiter is exposed as a feature of the VF, it doesn't matter 
> who really enforces it, the "VF portion" of the HW or the PF itself. I 
> agree that if you have to program the PF for the rate of a specific VF, 
> then its more complex. Basically, I would expect that a VF can be 
> configured with <mac, vlad-id, priority, rate> such that it can be done 
> where the VF NIC is spawned, host kernel or guest kernel.

Adding the rate limiter as a feature of the VF doesn't make much sense 
since the VF could be direct assigned to another OS for all we know so 
we won't have control over it from there.

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.  As such it is probably another thing we can bring up at the BOF 
session at the Linux Plumbers Conference.

> I'm was asking/wondering if the Intel NICs have a rate limiter (i.e one 
> can program the VF such that its rate doesn't exceed XX MB/s) or a "rate 
> guarantee"  (i.e one can program the VF such that its guaranteed it will 
> get YY MB/s in case it wants to xmit at least this bandwidth)

Based on the way I am reading the documentation I would say the all 
these registers do is guarantee a minimum percentage of the bandwidth. 
With these registers set you can repartition the traffic so that a 
percentage can be guaranteed to the PF/VFs if needed.  It works very 
similar to how DCB allows you to guarantee a certain amount of bandwidth 
for each of the traffic classes.  However any time the full tx bandwidth 
is not being used it will be reallocated to the other queues and then 
end up back in the default behavior.

The default behavior is to DMA descriptors from the rings in a round 
robin fashion.  Since this effectively guarantees that there will be 
packets being pulled off the rings I didn't really feel the necessity to 
add the additional overhead of doing this on a per PF/VF bandwidth basis.

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html