Re: [Xen-devel] Feature control on PV devices

[Juergen Gross <jgross@xxxxxxxx>]

On 15/09/17 13:19, Wei Liu wrote:
> On Thu, Sep 14, 2017 at 05:18:44PM +0100, Joao Martins wrote:
>> On 09/14/2017 05:10 PM, Wei Liu wrote:
>>> On Thu, Sep 07, 2017 at 05:53:54PM +0100, Joao Martins wrote:
>>>> Hey!
>>>>
>>>> We wanted to brought up this small proposal regarding the lack of
>>>> parameterization on PV devices on Xen.
>>>>
>>>> Currently users don't have a way for enforce and control what
>>>> features/queues/etc the backend provides. So far there's only global 
>>>> parameters
>>>> on backends, and specs do not mention anything in this regard.
>>>>
>>>> The most obvious example is netback/blkback max_queues module parameter 
>>>> where it
>>>> sets the limit the maximum queues for all devices which is not that 
>>>> flexible.
>>>> Other examples include controlling offloads visible by the NIC (e.g. 
>>>> disabling
>>>> checksum offload, disabling scather-gather), others more about I/O path 
>>>> (e.g.
>>>> disable blkif indirect descriptors, limit number of pages for the ring), 
>>>> or less
>>>> grant usage by minimizing number of queues/descriptors.
>>>>
>>>> Of course there could be more examples, as this seems to be ortoghonal to 
>>>> the
>>>> kinds of PV backends we have. And seems like all features appear to be 
>>>> published
>>>> on the same xenbus state?
>>>>
>>>> The idea to address this would be very simple:
>>>>
>>>> - Toolstack when initializing device paths, writes additional entries in 
>>>> the
>>>> form of 'request-<feature-name>' = <feature-value>. These entries are only
>>>> visible by the backend and toolstack;
>>>>
>>>> - Backend reads this entries and uses <feature-value> as the value of
>>>> <feature-name>, which will then be visible on the frontend.
>>>>
>>>> [ Removal of the 'request-*' xenstore entries could represent a feedback 
>>>> look
>>>>   that the backend indeed read and used the value. Or else it could simply 
>>>> be
>>>>   ignored. ]
>>>>
>>>> And that's it.
>>>>
>>>> In pratice user would do: E.g.
>>>>
>>>> domain.cfg:
>>>> ...
>>>> name = "guest"
>>>> kernel = "bzImage"
>>>> vif = ["bridge=br0,queues=2"]
>>>> disk = [
>>>> "format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2,queues=1,max-ring-page-order=0"
>>>
>>> There needs to be a way to distinguish parameters consumed by toolstack
>>> vs the ones passed on to backends. The parameters passed to backends
>>> should start with a predefined prefix.
>>>
>> Hmm, which seems to be inline with the "request" prefix when controlling 
>> certain
>> features enabled/disabled? Oh wait, perhaps you mean wrt to the 
>> UI/config-format
>> rather than xenstore entries and such? If it's the latter, see below,
> 
> I was thinking about xl config syntax.
> 
>>
>>>> ]
>>>> ...
>>>>
>>>> Toolstack writes:
>>>>
>>>> /local/domain/0/backend/vif/8/0/request-multi-queue-max-queues = 2
>>>> /local/domain/0/backend/vbd/8/51713/request-multi-queue-max-queues = 2
>>>> /local/domain/0/backend/vbd/8/51713/request-max-ring-page-order = 0

I'd rather use a specific directory, e.g.:

/local/domain/0/backend/vif/8/0/request/multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/request/multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/request/max-ring-page-order = 0

This will enable the backend to just look for all entries in
.../request/ instead of having to try all possible features.

>>>>
>>>> Backends reads and seeds with (and assuming it passes backend validation 
>>>> ofc):
>>>>
>>>> /local/domain/0/backend/vif/8/0/multi-queue-max-queues = 2
>>>> /local/domain/0/backend/vbd/8/51713/multi-queue-max-queues = 2
>>>> /local/domain/0/backend/vbd/8/51713/max-ring-page-order = 0
>>>>
>>>> The XL configuration entry for controlling these tunable are just examples 
>>>> it's
>>>> not clear the general preference for this. An alternative could be:
>>>>
>>>> vif = ["bridge=br0,features=queues:2\\;max-ring-page-order:0"]
>>>>
>>>> Which lets us have more generic feature control, without sticking to 
>>>> particular
>>>> features names.
>>>>
>>
>> In case the above was about config format, this one suggested above sounds 
>> more
>> general, and easy to reuse across backends. Maybe instead of "features", 
>> could
>> be "backend_features" since, most PV backends declare a "backend" and a
>> "backend_id" as per libxl IDL.
>>
> 
> The proposed syntax looks a bit difficult to parse.
> 
> What's wrong with request-XXX=YYY syntax? We can have many of those as
> we like. Xl just picks those and concatenate them into backend_features.

Is it possible to parse those without having to know about individual
XXX values? Otherwise we'd be able to support only features known by xl
instead of those known by the various backends.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel