[libvirt] [PATCH V3] Expose resource control capabilites on cache bank

[Martin Kletzander]

On Fri, Apr 07, 2017 at 05:47:54PM +0800, Eli Qiao wrote:
>>
>> The name doesn't really matter that much, 'scope' makes a bit more
>> sense, 'type' is consistent with the cache bank specification, I'm fine
>> with any. The big question here was if it is possible to have:
>>
>> <bank type='unified'>
>> <control scope='code'/>
>> <control scope='data'/>
>> </bank>
>>
>> And from what you say, the simple answer is "yes". So we need to have
>> the attribute there in the control element as well.
>>
>>
>
>
>Dan/Martin
>
>Could you please advice which should be changed ? LoL
>
>This is the output if I enabled CDP
>
>    <cache>
>      <bank id='0' level='3' type='unified' size='15360' unit='KiB' cpus='0-5'>
>        <control min='768' unit='KiB' type='instruction' nallocations='8'/>
>        <control min='768' unit='KiB' type='data' nallocations='8'/>
>      </bank>
>      <bank id='1' level='3' type='unified' size='15360' unit='KiB' cpus='6-11'>
>        <control min='768' unit='KiB' type='instruction' nallocations='8'/>
>        <control min='768' unit='KiB' type='data' nallocations='8'/>
>      </bank>
>    </cache>
>
>
>1. change nallocations to allocations/max_allocation?

Dan said he's fine with both, I'd probably go for max_allocations

>2. change type to scope ?

I don't care, pros for both in the previous mail.

>3. change `instruction` to `code` (with CDP enabled, it called DATA/CODE which is somewhat
>    different from /sys/fs/system/cpu/cpu*/cache/type, and I am now reuse virCacheType defined
>    by Martin, should I define another Type)?
>

Neither here do I really care.

If nobody has any other opinion by the end of the day, let's just go
with scope='both/data/code', with new virCacheScope (it should map to
respective values of virCacheType so we can use that in case we will
want to) as that is enum you might want to create anyway, so that you
have easier translation from/to kernel structures using
Type{To,From}String.

>
>>
>> P.S.: It would be clearly visible if you added the test case ;)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170407/cb147432/attachment-0001.sig>