Xen devel - Feb 2005 - Limiting Domains'' Network Network Transmit Rate

Hi,

I was wondering if it is possible to limit the rate of packet
transmission for individual domains.  The "Safe Hardware Access..."
paper mention''s a credit based scheduler for network transmission,
which
would seem to be perfect for what I need, however in the Xen netback
driver source code, the credit code seems to be taken out by the
pre-processor (with a "#if 0").

Would this credit code work if I put it back in, and if so, how can the
credit for each vif be set?  If this would not work is there any other
way of limiting the network transmission of individual domains?

Thanks for your help

Ross


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On 23 Feb 2005, at 15:02, Ross C Mcilroy wrote:
> I was wondering if it is possible to limit the rate of packet
> transmission for individual domains.  The "Safe Hardware
Access..."
> paper mention''s a credit based scheduler for network transmission,
> which
> would seem to be perfect for what I need, however in the Xen netback
> driver source code, the credit code seems to be taken out by the
> pre-processor (with a "#if 0").
>
> Would this credit code work if I put it back in, and if so, how can the
> credit for each vif be set?  If this would not work is there any other
> way of limiting the network transmission of individual domains?
Yes, we should add that back in at some point. An alternative is to use 
the existing ''tc'' functionality in Linux for network traffic
shaping
and policing.

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>> I was wondering if it is possible to limit the rate of packet
>> transmission for individual domains.  The "Safe Hardware
Access..."
>> paper mention''s a credit based scheduler for network
transmission,
>> which
>> would seem to be perfect for what I need, however in the Xen netback
>> driver source code, the credit code seems to be taken out by the
>> pre-processor (with a "#if 0").
>>
>> Would this credit code work if I put it back in, and if so, how can
the
>> credit for each vif be set?  If this would not work is there any
other
>> way of limiting the network transmission of individual domains?
>
>Yes, we should add that back in at some point. An alternative is to use
>the existing ''tc'' functionality in Linux for network
traffic shaping
>and policing.
>
>  -- Keir

How difficult would it be to put it back in?  If it was not a big job I
wouldn''t mind trying to get it working myself.  Why was it taken out in
the first place?

Thanks

Ross


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On 24 Feb 2005, at 09:59, Ross C Mcilroy wrote:
> How difficult would it be to put it back in?  If it was not a big job I
> wouldn''t mind trying to get it working myself.  Why was it taken
out in
> the first place?
Imprecision of the Linux jiffy-based timer. In fact this probably 
doesn''t matter.
Fairly coarse-grained shaping in which we specify credit periods of 
100s of
milliseconds would be adequate for most people''s needs.

It can probably be got working in the kernel again quite easily. 
Plumbing the new
feature through the control tool stack is an exercise for the reader. 
;-)

  -- Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>Imprecision of the Linux jiffy-based timer. In fact this probably 
>doesn''t matter.
>Fairly coarse-grained shaping in which we specify credit periods of 
>100s of
>milliseconds would be adequate for most people''s needs.

Is do_gettimeofday fast enough performance wise for the credit based
shaping, after all, it''s only called when the interface runs out of
credit. Correct me if I''m wrong, but do_gettimeofday has a higher
accuracy than the jiffy based timer?


Thanks

Ross


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>Is do_gettimeofday fast enough performance wise for the credit based
>shaping, after all, it''s only called when the interface runs out of
credit. >Correct me if I''m wrong, but do_gettimeofday has a higher
accuracy than the >jiffy based timer?

Sorry I was being stupid.  I thought you meant the time stamping didn''t
have good accuracy, re-reading your post I realise you meant the timer
scheduling.  

What is the best way to get the current time for the credit scheduler?
It seems to me that previously netback used something like time
functions in the hypervisitors time.h/c.  Where were these functions
placed in the Linux kernel, and are they still there?  Is this the best
thing to use, or are there better ways of going about it now?  Please
excuse me if these are daft, I''m new to Kernel hacking and Xen.


Thanks

Ross


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On 25 Feb 2005, at 15:45, Ross C Mcilroy wrote:
> What is the best way to get the current time for the credit scheduler?
> It seems to me that previously netback used something like time
> functions in the hypervisitors time.h/c.  Where were these functions
> placed in the Linux kernel, and are they still there?  Is this the best
> thing to use, or are there better ways of going about it now?  Please
> excuse me if these are daft, I''m new to Kernel hacking and Xen.
Just go with a jiffy-accurate scheduler and expect users to set credit 
periods suitably large that the imprecision won''t much matter. e.g., 
setting 2Mb credit every second is perhaps quite coarse-grained, but 
good enough control for most applications I think. If we need better 
then it can always be added later. Something simple that works is the 
way to go in the first instance.

  Cheers,
  Keir



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel