Re: [Xen-changelog] Plumb network vif credit-based rate limiting thorugh xenbus

Re: [Xen-changelog] Plumb network vif credit-based rate limiting thorugh xenbus

[Matt Ayres]

Xen patchbot -unstable wrote:
> # HG changeset patch
> # User kaf24@firebug.cl.cam.ac.uk
> # Node ID dadadf9aeee713bbe2f8dc040a74f7cea2223f41
> # Parent  2769a38f0e3e7ab544293833276a5d8cd0875483
> Plumb network vif credit-based rate limiting thorugh xenbus
> and xend into xm guest config files.
> 
> A new vif parameter 'rate' is supported, with an optional time window
> paremeter for specifying granularity of credit replenishment. The default
> window is 50ms. For example:
> 
>  'rate=10Mb/s'  'rate=250KB/s'  'rate=1MB/s@20ms'
> 

Is this rate in+out or out only?  Also, perhaps Chris could explain for 
us non-kernel hackers the purpose of specifying the credit replenishment 
  granularity and how it can be beneficial to tune it under certain 
circumstances?

Thank you,
Matt Ayres

Re: Re: [Xen-changelog] Plumb network vif credit-based rate limiting thorugh xenbus

[Keir Fraser]

On 1 Apr 2006, at 17:34, Matt Ayres wrote:

>> Plumb network vif credit-based rate limiting thorugh xenbus
>> and xend into xm guest config files.
>> A new vif parameter 'rate' is supported, with an optional time window
>> paremeter for specifying granularity of credit replenishment. The 
>> default
>> window is 50ms. For example:
>>  'rate=10Mb/s'  'rate=250KB/s'  'rate=1MB/s@20ms'
>
> Is this rate in+out or out only?  Also, perhaps Chris could explain 
> for us non-kernel hackers the purpose of specifying the credit 
> replenishment  granularity and how it can be beneficial to tune it 
> under certain circumstances?

This is out only, but could fairly easily be extended to input too.

Granularity determines the frequency with which the VIFs transmission 
credit is replenished. So, for example, if you specify 10MB/s@50ms then 
the VIF is credited with about 50 kilobytes of credit every 50ms. The 
credit does not accumulate.

A smaller replenishment window will make for slightly less bursty 
transmission, but there is an overhead as the replenishment rate is 
increased. Actually we believe that 50ms is a good tradeoff and I 
wouldn't really expect that anyone would bother to change it.

  -- Keir