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, ®s);
>
> /* 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
next prev 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).