From: Marc Sune <marc.sune@bisdn.de>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI
Date: Wed, 17 Jun 2015 10:23:55 +0200 [thread overview]
Message-ID: <55812E9B.9050200@bisdn.de> (raw)
In-Reply-To: <CAOaVG16+zaDDSdsshAGtTxtmus1+CAz1C9nM=_vCSDhkzPVmMQ@mail.gmail.com>
On 17/06/15 07:28, Stephen Hemminger wrote:
> On Tue, Jun 16, 2015 at 9:36 PM, Matthew Hall <mhall@mhcomputing.net> 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.
+1 to what Stephen says. I don't think though a higher level API is
really worth.
I unfortunately could not participate in the ABI discussion (there are
times in which you cannot be following each and every single thread in
the mailing list, and then it got lost in my inbox, my bad).
To me, ABI compatibility is a must if we'd have long term support
releases (1.8.0, 1.8.1...), which we don't (I proposed to have them a
couple of times).
On the other side, if the argument for ABI compatibility is shared
libraries and to make it easy to package for distros, I don't see
anything better than using the MAJOR.MIN version to identify the ABI
(1.8, 1.9). Having LTS support would also help distros be able to stay
in an ABI compatible version of DPDK and get recent bug fixes, and to
better identify ABi changes (MAJ.MIN).
Moreover, I doubt that many people use shared libraries in DPDK. DPDK is
built for performance and has a lot of code inlining which makes anyway
your binary to be recompiled, as Stephen says.
DPDK is still growing, and the strict ABI policy is forcing patches to
be delayed, to add hacky work-arounds to not break the ABI policy ( Re:
[dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in rte_mbuf as an
example) that are announced that have to be removed afterwards. I see
the entire ABI policy as a blocker and inducing to have botches all over
the code, than anything else.
Marc
next prev parent reply other threads:[~2015-06-17 8:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 23:29 Thomas Monjalon
2015-06-17 4:36 ` Matthew Hall
2015-06-17 5:28 ` Stephen Hemminger
2015-06-17 8:23 ` Thomas Monjalon
2015-06-17 8:23 ` Marc Sune [this message]
2015-06-17 11:17 ` Bruce Richardson
2015-06-18 16:32 ` Dumitrescu, Cristian
2015-06-18 13:25 ` Dumitrescu, Cristian
2015-06-17 9:54 ` Morten Brørup
2015-06-18 13:00 ` Dumitrescu, Cristian
2015-06-17 10:35 ` Neil Horman
2015-06-17 11:06 ` Richardson, Bruce
2015-06-19 11:08 ` Mcnamara, John
2015-06-17 12:14 ` Panu Matilainen
2015-06-17 13:21 ` Vincent JARDIN
2015-06-18 8:36 ` Zhang, Helin
2015-06-18 16:55 ` O'Driscoll, Tim
2015-06-18 21:13 ` Vincent JARDIN
2015-06-19 10:26 ` Neil Horman
2015-06-19 12:32 ` Thomas Monjalon
2015-06-19 13:02 ` Neil Horman
2015-06-19 13:16 ` Thomas Monjalon
2015-06-19 15:27 ` Neil Horman
2015-06-19 15:51 ` Thomas Monjalon
2015-06-19 16:13 ` Thomas F Herbert
2015-06-19 17:02 ` Thomas Monjalon
2015-06-19 17:57 ` Thomas F Herbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55812E9B.9050200@bisdn.de \
--to=marc.sune@bisdn.de \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).