From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id 99A77B380 for ; Tue, 12 Aug 2014 00:20:55 +0200 (CEST) Received: by mail-wi0-f181.google.com with SMTP id bs8so4915686wib.14 for ; Mon, 11 Aug 2014 15:23:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=6fDLvxBmnawuPc3TrT7UmTLxZ9eFzzfdEf/B0NXVfY8=; b=lKVuRbUk2vV57i8RV6BvfAa+GDhJ/iHER+S5VVwEovm2xvZ04bpRiSjXWNQmC3LeX6 DV4D5mS9z48/t1ik+2A00kASMp9ZCV0p9xOl1yarDm24dINPyumvHcX+65TLVkylIbln WTeKQzYMKXPRhF7pyObF5WQE1JxvRu+ZBG4Hh1Fba/HtvzECEfZIdb9eXl6QNrzlR59Q o5jwLWeCEJpIaFZJJ9EfwuIRl/bUhQ6i7oKBZL1LGYRRDmwTcayhDHIcLShTOzSNDB68 TNuYFzbVWd6kYdP21c/np7wyKMc1MEwdJfHDVhEkuDYrQYiGLuHeLX8gWbSMcLMPWorx pMlA== X-Gm-Message-State: ALoCoQmdKYAUe+Q6AWNHOMuqYmlv4MuhzF/btVYX7DYLb37JFV7huXRnzUQWaVLMdzfkOZ49T3YO X-Received: by 10.194.187.241 with SMTP id fv17mr681662wjc.13.1407795828175; Mon, 11 Aug 2014 15:23:48 -0700 (PDT) Received: from xps13.localnet (APoitiers-651-1-247-65.w83-193.abo.wanadoo.fr. [83.193.254.65]) by mx.google.com with ESMTPSA id u7sm48673037wif.3.2014.08.11.15.23.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Aug 2014 15:23:47 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Date: Tue, 12 Aug 2014 00:23:37 +0200 Message-ID: <9512671.ijrn2cbp2V@xps13> Organization: 6WIND User-Agent: KMail/4.13.3 (Linux/3.15.8-1-ARCH; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20140808143007.GA4723@hmsreliant.think-freely.org> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:20:55 -0000 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