From: Neil Horman <nhorman@tuxdriver.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features
Date: Wed, 30 Jul 2014 09:01:10 -0400 [thread overview]
Message-ID: <20140730130109.GA19737@localhost.localdomain> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725821345777@IRSMSX105.ger.corp.intel.com>
On Wed, Jul 30, 2014 at 12:07:39PM +0000, Ananyev, Konstantin wrote:
>
>
> Hi Neil,
>
> > Hey all-
> > I've been trying to update the fedora dpdk package to support VFIO
> > enabled drivers and ran into a problem in which ixgbe didn't compile because the
> > rxtx_vec code uses sse4.2 instruction intrinsics, which aren't supported in the
> > default config I have. I tried to remedy this by replacing the intrinsics with
> > the __builtin macros, but it was pointed out (correctly), that this doesn't work
> > properly. So this is my second attempt, which I actually like a bit better. I
> > noted that code that uses intrinsics (ixgbe and the acl library), don't need to
> > have those instructions turned on build-wide. Rather, we can just enable the
> > instructions in the specific code we want to build with support for that, and
> > test for instruction support dynamically at run time. This allows me to build
> > the dpdk for a generic platform, but in such a way that some optimizations can
> > be used if the executing cpu supports them at run time.
>
> Indeed it looks much better to me too.
> Just few nits from me:
>
> 1. > @@ -112,6 +112,15 @@ rte_acl_create(const struct rte_acl_param *param)
> > struct rte_acl_list *acl_list;
> > struct rte_tailq_entry *te;
> > char name[sizeof(ctx->name)];
> > + static int acl_supported = -1;
> > +
> > + if (acl_supported == -1)
> > + acl_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_SSE4_2);
>
> Do we really need acl_supported here?
> It seems not a big deal to just always call rte_cpu_get_flag_enabled().
> After all it is a create function, and no-one expects it to be extremely fast.
>
Need, no. My only thought was that some poorly behaved application will call
rte_acl_create multiple times regardless of the error returned, and doing so
will cause large volumes of calls to cpuid, which evicts several high-use
registers, so I didn't want to call it more than needed. If you think its ok to
call it multiple times though, I'm fine with removing it.
> 2. Can you add RTE_LOG(ERR, ...) for re_acl_create() and ixgbe_rx_vec_condition_check() if sse4.2 is not supported?
>
Absolutely, v2 shortly.
Neil
> Konstantin
>
>
next prev parent reply other threads:[~2014-07-30 12:59 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 20:24 Neil Horman
2014-07-29 20:24 ` [dpdk-dev] [PATCH 1/2] ixgbe: test sse4.2 support at runtime for vectorized receive operations Neil Horman
2014-07-29 20:24 ` [dpdk-dev] [PATCH 2/2] acl: Preform dynamic sse4.2 support check Neil Horman
2014-07-30 12:07 ` [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features Ananyev, Konstantin
2014-07-30 13:01 ` Neil Horman [this message]
2014-07-30 13:44 ` Ananyev, Konstantin
2014-07-30 14:49 ` [dpdk-dev] [PATCH v2 " Neil Horman
2014-07-30 14:49 ` [dpdk-dev] [PATCH v2 1/2] ixgbe: test sse4.2 support at runtime for vectorized receive operations Neil Horman
2014-07-30 14:49 ` [dpdk-dev] [PATCH v2 2/2] acl: Preform dynamic sse4.2 support check Neil Horman
2014-07-30 15:36 ` [dpdk-dev] [PATCH v2 0/2] dpdk: Allow for dynamic enablement of some isolated features Ananyev, Konstantin
2014-07-30 19:03 ` Venky Venkatesan
2014-07-30 19:17 ` Neil Horman
2014-07-30 19:34 ` Neil Horman
2014-07-30 18:59 ` [dpdk-dev] [PATCH " Bruce Richardson
2014-07-30 19:28 ` Neil Horman
2014-07-30 21:09 ` Bruce Richardson
2014-07-31 9:30 ` Thomas Monjalon
2014-07-31 11:36 ` Ananyev, Konstantin
2014-07-31 13:13 ` Neil Horman
2014-07-31 13:26 ` Thomas Monjalon
2014-07-31 14:32 ` Neil Horman
2014-07-31 18:10 ` Neil Horman
2014-07-31 18:36 ` Bruce Richardson
2014-07-31 19:01 ` Neil Horman
2014-07-31 20:19 ` Bruce Richardson
2014-08-01 13:36 ` Neil Horman
2014-08-01 13:56 ` Ananyev, Konstantin
2014-08-01 14:26 ` Venkatesan, Venky
2014-08-01 14:27 ` Neil Horman
2014-07-31 19:58 ` John W. Linville
2014-07-31 20:20 ` Bruce Richardson
2014-07-31 20:32 ` John W. Linville
2014-08-01 8:46 ` Vincent JARDIN
2014-08-01 14:06 ` Neil Horman
2014-08-01 14:57 ` Vincent JARDIN
2014-08-01 15:19 ` Neil Horman
2014-07-31 20:10 ` Neil Horman
2014-07-31 20:25 ` Bruce Richardson
2014-08-01 15:06 ` Neil Horman
2014-08-01 19:22 ` Bruce Richardson
2014-08-01 20:43 ` Neil Horman
2014-08-01 21:08 ` Bruce Richardson
2014-08-02 12:56 ` Neil Horman
2014-07-31 21:53 ` Thomas Monjalon
2014-07-31 21:25 ` Thomas Monjalon
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=20140730130109.GA19737@localhost.localdomain \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@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).