[dpdk-dev] [PATCH] librte_acl make it build/work for 'default' target

[Ananyev, Konstantin]

> -----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