Re: [RFC] [Design] Better XL support of RTDS scheduler for Xen 4.6

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-02-24 at 11:30 +0000, Dario Faggioli wrote:
> The problem is whether or not we allow overlap, i.e., whether the same
> parameters can live in both interfaces, and what is the semantic of
> that.

Ah, I see.

> Let's take RTDS as an example. budget and period make sense at the vcpu
> level so, as soon as we introduce the API for per-vcpu params, they
> should live there. But then what about the budget and period field we
> have in libxl_domain_sched_params? What's the meaning of them?

> Semantically speaking, they just should be killed. OTOH, what I was
> suggesting was this: if one calls libxl_domain_sched_params_set(), which
> takes a libxl_domain_sched_params, the budget and priod there will be
> interpreted as "for the whole domain", and applied to all the domain's
> vcpus. It's in this sense that I see it an either/or:
>  - at domain creation time, if the user does not say anything we'll use
>    the domain-wide API for setting a default budget and period for all
>    the vcpus.
>  - if the user does say something in the config file (once this will be
>    possible), or upon request, via the proper xl command, to modify the
>    parameters of vcpu X, we'll use the vcpu-wide API.

The simplest (and IMHO least surprising) thing would be to have the
per-vcpu ones override the per-domain ones. IOW per-domain sets a
default used unless a per-vcpu one says otherwise for a given vcpu.

So at build time you would first call the per-domain set function with
whatever parameters were provided, followed by setting any per-vcpu
options which are configured.

At run time via xl commands I guess they would be separate commands for
domains vs vcpus, and if you call the per-domain one I'd probably expect
it to clobber any existing per-vcpu settings (i.e act like the vcpu
option given --all).

> Of course this applies to parameters that are part of both
> structs/interfaces, which is something I was thinking to allow... were
> you?

Yes, I think it makes sense to have them.

Ian.