From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCHv2] librte_acl make it build/work for 'default' target Date: Tue, 12 Aug 2014 00:23:37 +0200 Message-ID: <9512671.ijrn2cbp2V@xps13> References: <1407436263-9360-1-git-send-email-konstantin.ananyev@intel.com> <2601191342CEEE43887BDE71AB977258213522BE@IRSMSX105.ger.corp.intel.com> <20140808143007.GA4723@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: "Ananyev, Konstantin" Return-path: In-Reply-To: <20140808143007.GA4723-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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. Thanks -- Thomas