On Wed, 2011-03-30 at 19:05 +0100, Dave Scott wrote:
> diff -r 62443233adf0 -r 2501899ab12f tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c Wed Mar 30 18:54:28 2011 +0100
> +++ b/tools/libxl/xl_cmdimpl.c Wed Mar 30 18:54:28 2011 +0100
> @@ -880,7 +880,10 @@ static void parse_config_data(const char
> nic->backend_domid = 0;
> }
> } else if (!strcmp(p, "rate")) {
> - fprintf(stderr, "the rate parameter for vifs is
> currently not supported\n");
> + if (sscanf(p2 + 1, "%"PRIu32",%"PRIu32,
> &(nic->qos_kb_per_sec), &(nic->qos_timeslice_usec)) != 2) {
> + fprintf(stderr, "Specified rate parameter needs to
> take the form: kb_per_sec,timeslice_usec\n");
> + break;
> + }
The xend equivalent to the xl function is
tools/python/xen/xend/server/netif.py parseRate() which seems to support
a different syntax to xapi:
rate_re = re.compile("^([0-9]+)([GMK]?)([Bb])/s(@([0-9]+)([mu]?)s)?$")
The xend syntax seems to be e.g. 1Mb/s@1ms.
I don't know how widely used the full power of this syntax is but our
general principal thus far has been to retain compatibility with xm
where we can.
Since the xend syntax allows for b/Mb/Kb suffixes and therefore byte
granularity that suggests the base unit for qos_kb_per_sec should
actually be bytes.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home