DPDK patches and discussions
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: "H. Peter Anvin" <hpa@linux.intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC UNTESTED PATCH] eal_common_cpuflags: Fix %rbx corruption, and simplify the code
Date: Thu, 20 Mar 2014 10:03:53 -0700	[thread overview]
Message-ID: <532B1F79.1050308@zytor.com> (raw)
In-Reply-To: <1395333868-2808-1-git-send-email-hpa@linux.intel.com>

I just realized there is yet another oddity in this code:

> @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
>  struct feature_entry {
>  	enum rte_cpu_flag_t feature;            /**< feature name */

The structure contains a field with an enum value...

>  	char name[CPU_FLAG_NAME_MAX_LEN];       /**< String for printing */
> -	struct cpuid_parameters_t params;       /**< cpuid parameters */
> -	uint32_t feature_mask;                  /**< bitmask for feature */
> +	uint32_t leaf;				/**< cpuid leaf */
> +	uint32_t subleaf;			/**< cpuid subleaf */
> +	uint32_t reg;				/**< cpuid register */
> +	uint32_t bit;				/**< cpuid register bit */
>  };
>  
>  
>  /*
> @@ -240,17 +207,20 @@ rte_cpu_get_features(struct cpuid_parameters_t params)
>  int
>  rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
>  {
> -	int value;
> +	const struct feature_entry *feat;
> +	cpu_registers_t regs;
>  
>  	if (feature >= RTE_CPUFLAG_NUMFLAGS)
>  		/* Flag does not match anything in the feature tables */
>  		return -ENOENT;
>  
> -	/* get value of the register containing the desired feature */
> -	value = rte_cpu_get_features(cpu_feature_table[feature].params);
> +	feat = &cpu_feature_table[feature];
> +
> +	/* get the cpuid leaf containing the desired feature */
> +	rte_cpu_get_features(feat->leaf, feat->subleaf, &regs);
>  
>  	/* check if the feature is enabled */
> -	return (cpu_feature_table[feature].feature_mask & value) > 0;
> +	return (regs[feat->reg] >> feat->bit) & 1;
>  }
>  
>  /**

... however, this field is never actually accessed *anywhere* in the
code; the code instead uses the enum value as the table index. There is
absolutely no enforcement that the table contents is aligned with the enum.

If C99-style initializers are permitted in this codebase, I would
strongly recommend using them, and then drop the enum field in struct
feature_entry and use a macro such as:

#define FEAT(name,leaf,subleaf,reg,bit) \
	[RTE_CPUFLAG_##f] = { leaf, subleaf, reg, bit, #f },

(I'd move the string to the end, but that is just a microoptimization.
I'm kind of OCD that way.)

	-hpa

  parent reply	other threads:[~2014-03-20 17:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 16:44 H. Peter Anvin
2014-03-20 16:55 ` Neil Horman
2014-03-20 17:03 ` H. Peter Anvin [this message]
2014-03-24 16:06   ` Neil Horman
2014-03-24 16:11     ` H. Peter Anvin
     [not found] <1395330830-1310-1-git-send-email-hpa@linux.intel.com>
2014-03-20 16:39 ` Neil Horman
2014-03-20 17:02   ` Thomas Monjalon
2014-03-20 18:04   ` Neil Horman

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=532B1F79.1050308@zytor.com \
    --to=hpa@zytor.com \
    --cc=dev@dpdk.org \
    --cc=hpa@linux.intel.com \
    /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).