From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 36063A05D3 for ; Wed, 24 Apr 2019 17:44:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 197EF1B505; Wed, 24 Apr 2019 17:44:22 +0200 (CEST) Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by dpdk.org (Postfix) with ESMTP id 225701B4FC for ; Wed, 24 Apr 2019 17:44:20 +0200 (CEST) Received: by mail-pl1-f193.google.com with SMTP id w24so9491626plp.2 for ; Wed, 24 Apr 2019 08:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=F+1sPlKNcD9AOOrZVdrkeWbGNVmO+AEowsB9gVyMobg=; b=g97MZXQ6gH6mcu+66X352Cmxi93MJFt5aaKYhwkiAD9/gWopWZsFXVWnZY5b+zw1cu gGLqMKpvrt5U11Llvft/DtQuwsnl1G05YkgTDetEZ/Zovi0lcTMD6lMWx0nfhRkb2KY4 FHeXkukvt4/849ETEqohPrVPgvfezIqHWYGLtu7bRekZbfqkrMwlUQQRbcpqcN+abO8P QLVG5UYE7B4O0AwAmGKF8WE+7IASgSkYL1v3kRrkVdRfJoMuqabKifk30O2SdAOfOhyx DxdO3EZYinSt/iy0ofupR+ihEiLYjMcUXoGkZR4D+umM9694nDzGRmlV6FNkMvECD/K2 4DvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=F+1sPlKNcD9AOOrZVdrkeWbGNVmO+AEowsB9gVyMobg=; b=OXUGiEKW0tV9UgZUCzq9siicLKxrur5lCONw+W3en1JCxf+qZyMJcoZEcAev2V5Dl3 SusC9nKKHIywW2js11opDGwCtECI5dE+TawrWbmRCjX7GIXZwaWjevRGvU7IEp5tWiP9 dcSkA9jaBbFXy2XRbpj/7sdgTFB0z/i+WISjtpd2DhIQMoZfdZfjeKCTaAYcwDsSxK/0 td7Dy7zmpf8xKSngVST+p4yWWwo76AenmPcfBJA0yJH0zDmanySKSobFGT44VExwMKEK tukGjb5v4wqSZE5dwK6ahKilXWQbagTKyvpxO/J8E50DxfWoplaI5NMjEYEu5aC0ZWFR GF8w== X-Gm-Message-State: APjAAAUkTuHWZ9wdGHLVucveUm7TndhF9wPGQOG+9/HsWjgjqzSTAZjm ojbqXS4Qb+7E6UdMxQEB31J5PA== X-Google-Smtp-Source: APXvYqxrnmx0KFYp41zn+3YpnZDZHbfZBP5tfeyUVDmBi6rdsT8TJEIHZioqQLpllmYzpkqboXKBWw== X-Received: by 2002:a17:902:2:: with SMTP id 2mr33545333pla.61.1556120658560; Wed, 24 Apr 2019 08:44:18 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id n65sm29930701pga.92.2019.04.24.08.44.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Apr 2019 08:44:18 -0700 (PDT) Date: Wed, 24 Apr 2019 08:44:10 -0700 From: Stephen Hemminger To: "Burakov, Anatoly" Cc: Ray Kinsella , Bruce Richardson , Honnappa Nagarahalli , "dev@dpdk.org" , "Ananyev, Konstantin" , "thomas@monjalon.net" , nd Message-ID: <20190424084410.389938ae@hermes.lan> In-Reply-To: <3cbef642-a6f5-760a-77b5-4d6fd19ef17a@intel.com> References: <20190417083637.GB1890@bricha3-MOBL.ger.corp.intel.com> <20190418102811.GB1817@bricha3-MOBL.ger.corp.intel.com> <2ec4da50-d874-865a-6bcc-916ac676be39@ashroe.eu> <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> <3cbef642-a6f5-760a-77b5-4d6fd19ef17a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] ABI and inline functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190424154410.VS2k14-Xszvy1VHcX6oyNKq7lhhvVYaWeo1qGG_66tg@z> On Wed, 24 Apr 2019 13:54:51 +0100 "Burakov, Anatoly" wrote: > On 24-Apr-19 1:22 PM, Ray Kinsella wrote: > >=20 > > On 24/04/2019 12:08, Burakov, Anatoly wrote: =20 > >> On 23-Apr-19 3:12 PM, Ray Kinsella wrote: =20 > >>> > >>> > >>> On 18/04/2019 11:28, Bruce Richardson wrote: =20 > >>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote= : =20 > >>>>>> > >>>>>> On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wro= te: =20 > >>>>>>> Hello, > >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0There was a conversation [1] in the cont= ext of RCU library. I > >>>>>>> thought > >>>>>>> it needs participation from broader audience. Summary for the con= text > >>>>>>> (please look at [1] for full details) > >>>>>>> =20 > >>>>>> > >>>>>> Thanks for kicking off this discussion > >>>>>> =20 > >>>>>>> 1) How do we provide ABI compatibility when the code base contain= s =20 > >>>>>> inline functions? Unless we freeze development in these inline > >>>>>> functions and > >>>>>> corresponding structures, it might not be possible to claim ABI > >>>>>> compatibility. > >>>>>> Application has to be recompiled. > >>>>>> > >>>>>> I agree that in some cases the application "might" need to be > >>>>>> recompiled, > >>>>>> but on the other hand I also think that there are many cases where= ABI > >>>>>> function versioning can still be used to mitigate things. For > >>>>>> example, if we > >>>>>> think of a couple of various scenarios: > >>>>>> > >>>>>> 1. If everything is inline and variables are allocated by app, e.g. > >>>>>> spinlock on stack, then there is no issue as everything is applica= tion > >>>>>> contained. =20 > >>>>> If there is a bug fix which requires the structure to change, the > >>>>> application would need to recompile. I guess you are talking about a > >>>>> scenario when nothing changed in the inline function/variables. > >>>>> =20 > >>>> > >>>> If the application wants the bugfix, then yes. However, if the app is > >>>> unaffected by the bug, then it should have the option of updating DP= DK > >>>> without a recompile. =20 > >>> > >>> I would also imagine that should be an extremely rare case, that a > >>> bugfix would require a structure change ... perhaps for an alignment > >>> issues? =20 > >> > >> Multiprocess threading issues is one case i've had to do that more than > >> once. =20 > >=20 > > Another reason to dislike multi process I guess. > > =20 > >> > >> > >> > >> =20 > >>> > >>> The reality is that most other system libraries provide strong > >>> guarantees ... to date we have provided very little. > >>> =20 > >> > >> To our credit, the libraries you're likely referring to aren't trying = to > >> reimplement the Linux kernel :) I don't think we do these API/ABI brea= ks > >> just because we like doing them - DPDK is complex, and getting > >> everything right the first time *and* allowing for future evolution is > >> not a trivial undertaking. > >> > >> > >> To me, part of the problem is that DPDK is an "everything and the > >> kitchen sink" kind of library where there is a bunch of drivers, a who= le > >> quasi-OS layer of dealing with hardware in a cross-platform manner, a > >> separate memory management system, a bunch of libraries such as hash/l= pm > >> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a > >> library" would concentrate on doing one thing well. DPDK, on the other > >> hand, tries to do *everything* well. The sheer breadth of DPDK's scope > >> is, i think, contributing to the breakages. If you keep 99% of your > >> libraries stable between version, but there's a small ABI tweak in an > >> LPM library, the entire DPDK stability gets invalidated. =20 > >=20 > > Well I guess DPDK is no more complex than Java or .NET Framework in that > > respect, as these also feature OS-layers, memory management systems, > > application frameworks, primitives etc but do manage to give their > > consumers strong guarantee's on API stability. Clearly ABI stability has > > a no meaning when you always being JIT compiled. =20 >=20 > I was basing my response on your earlier comparisons of DPDK to=20 > GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but= =20 > then these frameworks generally go through much more rigorous=20 > development/design cycle than DPDK does - DPDK's API design process is=20 > pretty ad-hoc, while both Java and .NET have various kinds of procedures= =20 > by which things get into the standard library. If we're prepared to do=20 > that - i'm all for it. What we can't have is stability *and* keep the=20 > same approach to design/development that we have now. >=20 Lets step back a bit. I think some of the basic business rules which go back to the "Innovators dilemma" are that it is NOT a good idea to pay too much attention to existing customers. Instead, it is important to pay attention to the need of the potential customers that could use your product. In this case, my argument is that it is important for the DPDK project to pay more attention to the reasons that new users do not want to use the project; and existing users do not want to upgrade. This problem has been repeatedly expressed as: "DPDK is not stable". The project needs to address that concern even if it means a 1% drop in performance. Surely that 1% can be made up by improving other places. Even using link-time-optimization can give 2 to 5 % back.