>>> On 10.03.17 at 06:40, <yi.y....@linux.intel.com> wrote:
> On 17-03-09 07:10:33, Jan Beulich wrote:
>> >>> On 15.02.17 at 09:49, <yi.y....@linux.intel.com> wrote:
>> > @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[],
>> > return 0;
>> > }
>> >
>> > +static bool l3_cat_fits_cos_max(const uint64_t val[],
>> > + const struct feat_node *feat,
>> > + unsigned int cos)
>> > +{
>> > + uint64_t l3_def_cbm;
>> > +
>> > + l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1;
>>
>> Seeing this pattern recur I wonder whether this also wouldn't be
>> something that could be stored once in a generic manner, avoiding
>> the need for this per-feature callback (cos_max should be common
>> to all features too - not the values, but the abstract notion - so
>> perhaps get_cos_max() isn't needed as a callback either).
>>
> DYM to create a member in 'struct feat_node'? E.g:
> uint64_t def_val;
Yes. All data items applicable to all features should be outside
the feature dependent data structures. And which pieces of
data to store you should determine by the overall aim of
preferably as little feature-specific code as possible, i.e.
whatever can be made common with reasonable effort should
be made common.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
