[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 04/15] x86: refactor psr: Encapsulate 'cbm_len' and 'cbm_max'



On 16-11-25 09:57:31, Jan Beulich wrote:
> >>> On 25.11.16 at 17:27, <JBeulich@xxxxxxxx> wrote:
> >>>> On 25.10.16 at 05:40, <yi.y.sun@xxxxxxxxxxxxxxx> wrote:
> >> 'cbm_len' and 'cbm_max' are CAT/CDP specific feature HW info.
> >> So encapsulate them into 'struct psr_cat_hw_info'. If new
> >> feature is supported, we can define other structure to save
> >> its HW info.
> > 
> > Part of my problem following you here is that you talk about
> > cbm_max, but the code changes cos_max, which so far I had
> > understood would be a generic limit,
> 
> So I've gone and looked back at patch 1, where indeed you say
> the limits might differ. Which raises the question then what
> opt_cos_max is representing.
> 
> Having seen v1, v2, and v3 up to patch 5 I start wondering
> whether the whole current code wouldn't better be ripped out
> and then be replaced by something written from scratch. That's
> because the split, while having reduced individual patch size,
> doesn't really make the whole thing much better reviewable.
> And the original implementation apparently simply didn't have
> in mind how future additions on the hardware side could look
> like.
> 
> Thoughts?
> 
> Jan

Firstly, I want to say sorry that the V3 still does not make you
feel good. I planned to split the big patch based on data structure
changes to make you understand more easily.

The original implementation of psr.c does not consider much about
future features because there was only L3 CAT introduced and we do
not know there will be new features and how they work. That is the
reason I refactor the psr.c to make it be easy to add new features
by abstracting the common things.

To make codes be better reviewable, I propose below three suggestions:
1) I write a design document about refactor to make you more easily 
understand the ideas.
2) Replace the psr.c with a new file which discards all old codes so
that you do not need to consider old implementations which may cause
confusion.
3) Discard the refactor codes. Just implement L2 CAT based on current
codes. Because L2 CAT does not have much difference with L3.

How do you think? If you can offer your ideas to design and implement
the codes, that would be a great opportunity for me to learn! Thank you!

BRs,
Sun Yi

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.