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

Thomas Monjalon thomas.monjalon at 6wind.com
Tue Aug 12 00:23:37 CEST 2014

Hi all,

2014-08-08 10:30, Neil Horman:
> On Fri, Aug 08, 2014 at 01:09:34PM +0000, Ananyev, Konstantin wrote:

> > > > Also I think user should have an ability to change default classify code path without modifying/rebuilding acl library.
> > > I agree, but both the methods we are advocating for allow that.  Its really just
> > > a question of exposing the mechanism as data or text in the binary.  Exposing it
> > > as data comes with implicit ABI constraints that are less prevalanet when done
> > > as code entry points.
> >  
> > > > For example: a bug in an optimised code path is discovered, or user may want to implement and use his own version of classify().
> > Of course, he probably will report about it and we probably fix it sooner or later.
> > But with such ability he can switch to the safe implementation immediately
> > without touching the library and then wait for the fix.
> Thats not how users of a binary pacakge from a distribution operate.  If their
> using a binary package they either:
> 1) Don't want to rebuild anything themselves, in which case they file the bug,
> and wait for the developers to fix the issue.
> or 
> 2) Have a staff to help them work around the issue, which will be done by
> rebuilding/fixing the library, not the application.
> With (2), what I am saying is that, if a 3rd party finds a bug in the classifier
> code within dpdk which is built as a shared library within a distribution, and
> they need it fixed immediately, they have a choice of what to do, they can
> either (a), write a custom classifier function and point the dpdk library to it,
> or (b), just fix the bug in the library directly.  Given that, if they can
> accomplish (a), they by all rights can also accompilsh (b), the only decision
> they need to make is one which makes the most sense for them.  The answer is
> (b), because thats where the functionality lives.  i.e. when the fix occurs
> upstream and a new release gets issued, you can go back to using the library
> maintained version, and you don't have to clean up what has become vestigial
> unused code.

I think it's even simpler: thinking API to allow behaviour changes without
rebuilding is not sane. So we should expose all functions?

Please try to reduce API as much as possible.

More information about the dev mailing list