Re: [PATCH v2 20/33] x86/intel_rdt.h: Header for inter_rdt.c

From: Thomas Gleixner <tglx@linutronix.de>
To: Fenghua Yu <fenghua.yu@intel.com>
Cc: "H. Peter Anvin" <h.peter.anvin@intel.com>,
	Ingo Molnar <mingo@elte.hu>, Tony Luck <tony.luck@intel.com>,
	Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
	Borislav Petkov <bp@suse.de>,
	Stephane Eranian <eranian@google.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	David Carrillo-Cisneros <davidcc@google.com>,
	Shaohua Li <shli@fb.com>,
	Ravi V Shankar <ravi.v.shankar@intel.com>,
	Vikas Shivappa <vikas.shivappa@linux.intel.com>,
	Sai Prakhya <sai.praneeth.prakhya@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v2 20/33] x86/intel_rdt.h: Header for inter_rdt.c
Date: Thu, 8 Sep 2016 14:36:54 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1609081241360.5647@nanos> (raw)
In-Reply-To: <1473328647-33116-21-git-send-email-fenghua.yu@intel.com>

On Thu, 8 Sep 2016, Fenghua Yu wrote:

Subject: x86/intel_rdt.h: Header for inter_rdt.c

inter_rdt? I know about Inter Mailand ....

> The header mainly provides functions to call from the user interface
> file intel_rdt_rdtgroup.c.

What the heck? We do not introduce function prototypes and whatever crap
without an implementation. We add the stuff when we add a function or
implement something which needs a define/struct whatever.

> +enum resource_type {
> +	RESOURCE_L3  = 0,
> +	RESOURCE_NUM = 1,

Why does this need an explicit enum initialization?

> +};
> +
> +#define MAX_CACHE_LEAVES        4
> +#define MAX_CACHE_DOMAINS       64
> +
> +DECLARE_PER_CPU_READ_MOSTLY(int, cpu_l3_domain);
> +DECLARE_PER_CPU_READ_MOSTLY(struct rdtgroup *, cpu_rdtgroup);
>  
>  extern struct static_key rdt_enable_key;
>  void __intel_rdt_sched_in(void *dummy);
>  
> +extern bool cdp_enabled;
> +
> +struct rdt_opts {
> +	bool cdp_enabled;
> +	bool verbose;
> +	bool simulate_cat_l3;
> +};
> +
> +struct cache_domain {
> +	cpumask_t shared_cpu_map[MAX_CACHE_DOMAINS];
> +	unsigned int max_cache_domains_num;
> +	unsigned int level;
> +	unsigned int shared_cache_id[MAX_CACHE_DOMAINS];
> +};
> +
> +extern struct rdt_opts rdt_opts;
> +
>  struct clos_cbm_table {
>  	unsigned long cbm;
>  	unsigned int clos_refcnt;
>  };
>  
>  struct clos_config {
> -	unsigned long *closmap;
> +	unsigned long **closmap;
>  	u32 max_closid;
> -	u32 closids_used;
>  };
>  
> +struct shared_domain {
> +	struct cpumask cpumask;
> +	int l3_domain;
> +};
> +
> +#define for_each_cache_domain(domain, start_domain, max_domain)	\
> +	for (domain = start_domain; domain < max_domain; domain++)
> +
> +extern struct clos_config cconfig;
> +extern struct shared_domain *shared_domain;
> +extern int shared_domain_num;
> +
> +extern struct rdtgroup *root_rdtgrp;
> +
> +extern struct clos_cbm_table **l3_cctable;
> +
> +extern unsigned int min_bitmask_len;
> +extern void msr_cpu_update(void *arg);
> +extern inline void closid_get(u32 closid, int domain);

extern inline?

> +extern void closid_put(u32 closid, int domain);

That's declared static in the source, but sure you do not notice because
intel_rdc.c is not hooked up to the Makefile yet.....

> +extern void closid_free(u32 closid, int domain, int level);

is declared static inline ....

> +extern int closid_alloc(u32 *closid, int domain);

amd more of this crap to follow.

I explicitely asked you last time to do:

>> Which is not making the review any simpler. In order to understand the
>> modifications I have to go back and page in the original stuff from last
>> year once again. So I have to read the original patch first to
>> understand the modifications and then get the overall picture of the new
>> stuff. Please fold stuff back to the proper places so I can start
>> reviewing this thing under the new design idea instead of twisting my
>> brain around two designs.

And you replied:

> Ok. I will do that.

Actually you did the reverse. You introduced more crap in the original
patches. See 12/32 vs. the previous version 
http://marc.info/?l=linux-kernel&m=146836100821478

What's the value of mechanically split patches which cannot even compile on
their own? Nothing at all except creating the hell for reviewers.

Thanks,

	tglx