[dpdk-dev] [PATCH] librte_acl make it build/work for 'default' target
Ananyev, Konstantin
konstantin.ananyev at intel.com
Thu Aug 7 18:13:44 CEST 2014
> -----Original Message-----
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, August 06, 2014 7:55 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] librte_acl make it build/work for 'default' target
>
> On Wed, Aug 06, 2014 at 06:53:45PM +0100, Konstantin Ananyev wrote:
> > Make ACL library to build/work on 'default' architecture:
> > - make rte_acl_classify_scalar really scalar
> > (make sure it wouldn't use sse4 instrincts through resolve_priority()).
> > - Provide two versions of rte_acl_classify code path:
> > rte_acl_classify_sse() - could be build and used only on systems with sse4.2
> > and upper, return -ENOTSUP on lower arch.
> > rte_acl_classify_scalar() - a slower version, but could be build and used
> > on all systems.
> > - rte_acl_classify() - becomes just a macro pointing to one of the functions
> > mentioned abovei (highest avaialbe version at build time).
> > - keep code common for both version code.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> > ---
> > lib/librte_acl/acl_bld.c | 5 +-
> > lib/librte_acl/acl_match_check.def | 92 +++++
> > lib/librte_acl/acl_run.c | 692 ++++---------------------------------
> > lib/librte_acl/acl_run_sse.h | 629 +++++++++++++++++++++++++++++++++
> > lib/librte_acl/rte_acl.h | 12 +-
> > 5 files changed, 806 insertions(+), 624 deletions(-)
> > create mode 100644 lib/librte_acl/acl_match_check.def
> > create mode 100644 lib/librte_acl/acl_run_sse.h
> >
> This is still compile time selected. You've gone to all the trouble to separate
> the scalar and sse vector paths. Why not make it run time selectable based on
> cpu testing? Just because its built for the default machine doesn't mean it
> will run on the default machine. We may as well take advantage of the faster
> paths when we're able.
>
Yes, it is possible to make selection at run-time...
Though I suppose it might add some overhead (extra call (or jump), etc.).
But ok, I'll see what I can do.
Konstantin
More information about the dev
mailing list