From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by dpdk.org (Postfix) with ESMTP id B8BBEC3A0 for ; Wed, 17 Jun 2015 07:28:17 +0200 (CEST) Received: by igbsb11 with SMTP id sb11so29579911igb.0 for ; Tue, 16 Jun 2015 22:28:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QrKBKJ6oI2QKbKJxVzNx6awZ9Y13m5LRKslhCzTZpWg=; b=TwJvDXuKJdRzTXdfrvm8+xJzj5hnmWa24ZVcHcgVSmIdFheloUm3aKuC0V3X+awNRU j4kar8jWfNWz/VHhkan4AGlI9oyUM4r8Ue5m40Aatg9kv6ZbCdf5HkvBgN1mDeBTj2OQ hwO//SDokIrOdlchU/kDnyoxCJxl8NvZNwgLAJANRrmgSmdxT9xel4LWAU6IstiUU8qv VK2GqftlsTORtkAtvBg7ORXaSSwtLP9EwJoi90Zk5jlqfD6tK+0MhtRZIpLx3YAfW8QM rSxFJVerunDeHOvohhBAdGTqxHuc2NkZPC6ca7OMr4i7n+P4fKD7FZMgiLT0s24FDfy4 PK7w== X-Gm-Message-State: ALoCoQkQCmhOeE2aPk8vukngBFS8nAsw4A11efxgLGWy196Y1LfXddZa6FQHhha/EWlBLtOEhqEN MIME-Version: 1.0 X-Received: by 10.50.178.133 with SMTP id cy5mr32216609igc.5.1434518897053; Tue, 16 Jun 2015 22:28:17 -0700 (PDT) Received: by 10.64.9.237 with HTTP; Tue, 16 Jun 2015 22:28:16 -0700 (PDT) In-Reply-To: <20150617043654.GA10337@mhcomputing.net> References: <9092314.MoyqUJ5VU2@xps13> <20150617043654.GA10337@mhcomputing.net> Date: Tue, 16 Jun 2015 22:28:16 -0700 Message-ID: From: Stephen Hemminger To: Matthew Hall Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI 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: Wed, 17 Jun 2015 05:28:18 -0000 On Tue, Jun 16, 2015 at 9:36 PM, Matthew Hall wrote: > On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote: > > There were some debates about software statistics disabling. > > Should they be always on or possibly disabled when compiled? > > We need to take a decision shortly and discuss (or agree) this proposal: > > http://dpdk.org/ml/archives/dev/2015-June/019461.html > > This goes against the idea I have seen before that we should be moving > toward > a distro-friendly approach where one copy of DPDK can be used by multiple > apps > without having to rebuild it. It seems like it is also a bit ABI hostile > according to the below goals / discussions. > > Jemalloc is also very high-performance code and still manages to allow > enabling and disabling statistics at runtime. Are we sure it's impossible > for > DPDK or just theorizing? > > > During the development of the release 2.0, there was an agreement to keep > > ABI compatibility or to bring new ABI while keeping old one during one > release. > > In case it's not possible to have this transition, the (exceptional) > break > > should be acknowledged by several developers. > > Personally to me it seems more important to preserve the ABI on patch > releases, like 2.X.Y going to 2.X.Z. But maybe I missed something? > > > During the current development cycle for the release 2.1, the ABI > question > > arises many times in different threads. > > Most but not all of these examples point to a different issue which > sometimes > happens in libraries... often seen as "old-style" versus "new-style" C > library > interface. For example, in old-style like libpcap there are a lot of > structs, > both opaque and non-opaque, which the caller must allocate in order to run > libpcap. > > However new-style libraries such as libcurl usually just have init > functions > which initialize all the secret structs based on some defaults and some > user > parameters and hide the actual structs from the user. If you want to adjust > some you call an adjuster function that modifies the actual secret struct > contents, with some enum saying what field to adjust, and the new value you > want it to have. > > If you want to keep a stable ABI for a non-stable library like DPDK, > there's a > good chance you must begin hiding all these weird device specific structs > all > over the DPDK from the user needing to directly allocate and modify them. > Otherwise the ABI breaks everytime you have to add adjustments, extensions, > modifications to all these obscure special features. > > Matthew. > The DPDK makes extensive use of inline functions which prevents data hiding necessary for ABI stablility. This a fundamental tradeoff, and since the whole reason for DPDK is performance; the ABI is going to be a moving target. It would make more sense to provide a higher level API which was abstracted, slower, but stable for applications. But in doing so it would mean giving up things like inline lockless rings. Just don't go as far as the Open (not) dataplane API; which is just an excuse for closed source.