xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Yi Sun <yi.y.sun@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: wei.liu2@citrix.com, he.chen@linux.intel.com,
	andrew.cooper3@citrix.com, dario.faggioli@citrix.com,
	ian.jackson@eu.citrix.com, mengxu@cis.upenn.edu,
	xen-devel@lists.xenproject.org, chao.p.peng@linux.intel.com
Subject: Re: [PATCH v4 03/24] x86: refactor psr: implement main data structures.
Date: Tue, 3 Jan 2017 18:28:08 +0800	[thread overview]
Message-ID: <20170103102808.GQ7435@yi.y.sun> (raw)
In-Reply-To: <586B7925020000780012C859@prv-mh.provo.novell.com>

On 17-01-03 02:12:53, Jan Beulich wrote:
> >>> On 03.01.17 at 09:49, <yi.y.sun@linux.intel.com> wrote:
> > On 17-01-03 01:00:37, Jan Beulich wrote:
> >> >>> On 26.12.16 at 07:56, <yi.y.sun@linux.intel.com> wrote:
> >> > On 16-12-22 09:13:43, Jan Beulich wrote:
> >> >> >>> On 14.12.16 at 05:07, <yi.y.sun@linux.intel.com> wrote:
> >> >> > +struct feat_node;
> >> >> > +
> >> >> > +/*
> >> >> > + * This structure defines feature operation callback functions. Every feature
> >> >> > + * enabled MUST implement such callback functions and register them to ops.
> >> >> > + *
> >> >> > + * Feature specific behaviors will be encapsulated into these callback
> >> >> > + * functions. Then, the main flows will not be changed when introducing a new
> >> >> > + * feature.
> >> >> > + */
> >> >> > +struct feat_ops {
> >> >> > +    /*
> >> >> > +     * init_feature is used in cpu initialization process to do feature
> >> >> > +     * specific initialization works.
> >> >> > +     */
> >> >> > +    void (*init_feature)(unsigned int eax, unsigned int ebx,
> >> >> > +                         unsigned int ecx, unsigned int edx,
> >> >> > +                         struct feat_node *feat,
> >> >> > +                         struct psr_socket_info *info);
> >> >> > +};
> >> >> 
> >> >> What is the reason to have a separate structure for this, when you
> >> >> don't store a pointer in struct feat_node? If this was inlined there,
> >> >> the odd forward declaration of struct feat_node wouldn't be needed
> >> >> either. (The same question may apply to struct feat_hw_info.) 
> >> >> 
> >> > I just want to make codes be clear. If you prefer inline declaration, I 
> >> > think I
> >> > should change it as below, right?
> >> > 
> >> > struct feat_node {
> >> > ......
> >> >     struct feat_ops {
> >> >         ......
> >> >     } ops;
> >> >     struct feat_hw_info {
> >> >         ......
> >> >     } info;
> >> > ......
> >> > };
> >> 
> >> Well, not exactly: The struct <tag> { ... } <name>; wrappers
> >> are unnecessary then too. With them kept there indeed would be
> >> no big difference between both variants.
> >> 
> > To facilitate the callback functions assignment for a feature, I defined
> > feature specific callback function ops like below.
> > 
> > struct feat_ops l3_cat_ops = {
> >     .init_feature = l3_cat_init_feature,
> >     .get_max_cos_max = l3_cat_get_max_cos_max,
> >     ......
> > };
> > 
> > And directly assign it to global feature node in initialization process like
> > below.
> > 
> > static void cpu_init_work(void)
> > {
> > ......
> >             feat_tmp = feat_l3_cat;
> >             feat_l3_cat = NULL;
> >             feat_tmp->ops = l3_cat_ops;
> > ......
> > }
> > 
> > I think this can make codes be clear. How do you think? Is this way 
> > acceptable?
> 
> Yes.
> 
Thanks a lot! Do you have any comment to other patches?

> Jan

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

  reply	other threads:[~2017-01-03 10:28 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14  4:07 [PATCH v4 00/24] Enable L2 Cache Allocation Technology & Refactor psr.c Yi Sun
2016-12-14  4:07 ` [PATCH v4 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document Yi Sun
2016-12-14  4:07 ` [PATCH v4 02/24] x86: refactor psr: remove L3 CAT/CDP codes Yi Sun
2016-12-22 16:03   ` Jan Beulich
2016-12-26  2:28     ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 03/24] x86: refactor psr: implement main data structures Yi Sun
2016-12-22 16:13   ` Jan Beulich
2016-12-26  6:56     ` Yi Sun
2017-01-03  8:00       ` Jan Beulich
2017-01-03  8:49         ` Yi Sun
2017-01-03  9:12           ` Jan Beulich
2017-01-03 10:28             ` Yi Sun [this message]
2017-01-03 11:23               ` Jan Beulich
2016-12-14  4:07 ` [PATCH v4 04/24] x86: refactor psr: implement CPU init and free flow Yi Sun
2017-01-10 11:45   ` Jan Beulich
2017-01-11  3:14     ` Yi Sun
2017-01-11 13:48       ` Jan Beulich
2017-01-12  1:07         ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 05/24] x86: refactor psr: implement Domain init/free and schedule flows Yi Sun
2017-01-10 13:34   ` Jan Beulich
2017-01-11  3:17     ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 06/24] x86: refactor psr: implement get hw info flow Yi Sun
2017-01-10 13:46   ` Jan Beulich
2017-01-11  5:13     ` Yi Sun
2017-01-11 13:53       ` Jan Beulich
2017-01-12  1:08         ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 07/24] x86: refactor psr: implement get value flow Yi Sun
2017-01-10 13:50   ` Jan Beulich
2017-01-11  5:16     ` Yi Sun
2017-01-11 13:54       ` Jan Beulich
2017-01-12  1:09         ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 08/24] x86: refactor psr: set value: implement framework Yi Sun
2017-01-10 14:17   ` Jan Beulich
2017-01-11  5:57     ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 09/24] x86: refactor psr: set value: assemble features value array Yi Sun
2017-01-10 14:34   ` Jan Beulich
2017-01-11  6:07     ` Yi Sun
2017-01-11 13:57       ` Jan Beulich
2017-01-12  1:17         ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 10/24] x86: refactor psr: set value: implement cos finding flow Yi Sun
2017-01-10 14:53   ` Jan Beulich
2017-01-11  6:10     ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 11/24] x86: refactor psr: set value: implement cos id allocation flow Yi Sun
2017-01-10 15:08   ` Jan Beulich
2017-01-11  6:16     ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 12/24] x86: refactor psr: set value: implement write msr flow Yi Sun
2017-01-10 15:15   ` Jan Beulich
2017-01-11  6:22     ` Yi Sun
2017-01-11 14:01       ` Jan Beulich
2017-01-12  1:22         ` Yi Sun
2017-01-12  9:40           ` Jan Beulich
2017-01-12 10:22             ` Yi Sun
2016-12-14  4:07 ` [PATCH v4 13/24] x86: refactor psr: implement CPU init and free flow for CDP Yi Sun
2016-12-14  4:07 ` [PATCH v4 14/24] x86: refactor psr: implement get hw info " Yi Sun
2016-12-14  4:07 ` [PATCH v4 15/24] x86: refactor psr: implement get value " Yi Sun
2016-12-14  4:07 ` [PATCH v4 16/24] x86: refactor psr: implement set value callback functions " Yi Sun
2016-12-14  4:07 ` [PATCH v4 17/24] x86: L2 CAT: implement CPU init and free flow Yi Sun
2016-12-14  4:07 ` [PATCH v4 18/24] x86: L2 CAT: implement get hw info flow Yi Sun
2016-12-14  4:07 ` [PATCH v4 19/24] x86: L2 CAT: implement get value flow Yi Sun
2016-12-14  4:08 ` [PATCH v4 20/24] x86: L2 CAT: implement set " Yi Sun
2016-12-14  4:08 ` [PATCH v4 21/24] tools: L2 CAT: support get HW info for L2 CAT Yi Sun
2017-01-06 12:04   ` Wei Liu
2017-01-09  1:19     ` Yi Sun
2017-01-09  8:31       ` Jan Beulich
2017-01-09  9:26         ` Wei Liu
2017-01-10  8:00           ` Yi Sun
2017-01-10  8:46             ` Jan Beulich
2017-01-10  9:01               ` Yi Sun
2016-12-14  4:08 ` [PATCH v4 22/24] tools: L2 CAT: support show cbm " Yi Sun
2017-01-06 12:04   ` Wei Liu
2017-01-09  1:24     ` Yi Sun
2017-01-09 10:08       ` Wei Liu
2017-01-10  7:47         ` Yi Sun
2016-12-14  4:08 ` [PATCH v4 23/24] tools: L2 CAT: support set " Yi Sun
2017-01-06 12:04   ` Wei Liu
2017-01-09  1:14     ` Yi Sun
2016-12-14  4:08 ` [PATCH v4 24/24] docs: add L2 CAT description in docs Yi Sun
2017-01-06 12:04   ` Wei Liu
2017-01-09  1:25     ` Yi Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170103102808.GQ7435@yi.y.sun \
    --to=yi.y.sun@linux.intel.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=dario.faggioli@citrix.com \
    --cc=he.chen@linux.intel.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=mengxu@cis.upenn.edu \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).