From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 2885DC444 for ; Wed, 17 Jun 2015 15:21:34 +0200 (CEST) Received: by wiga1 with SMTP id a1so139486599wig.0 for ; Wed, 17 Jun 2015 06:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oerlovBZTNgRf4W/Lna5eXQmLrnhEVDqP+Iw5Ud+p0Y=; b=M/w7h9bi//WAjno1+lZ9woVYpQ5xnQJDpM47+jezW2PQiB4VnHgzZ6Pm5MTCPF7AyJ Bnu4qu3GCcnzQ0n5AmfRSHf2k6ySrhpfkY3zVQ1vHpZ82F8D8CjL684b4S+S9tKymIMA rCbaKjGGkG2MfH7ivtTHgKfNz6/mUYLe2OfRoxxhp+g9u/PUPu2F6Aceal6TpXMiggli tknstd4oI+Y+t86WWEZtVSN28+fU0cESdcSezNqb3sVrfcTDYthXwVQoyPKNabmIV6t/ 7fYwiJ4liPFKrIQp0AI/UtQdsLyFL/9JovPbONw5okzZ3YFqbVTCuDVj3GNdiFq46TiZ CF1w== X-Gm-Message-State: ALoCoQk5X9m0yzcd2dlAHsmdfkKGt0UUMYJ+3GzPrK/UJpTtnLYRxVNJuukJjc6g/WhPJ9IpcbF6 X-Received: by 10.180.36.170 with SMTP id r10mr18268146wij.10.1434547293966; Wed, 17 Jun 2015 06:21:33 -0700 (PDT) Received: from saturne.dev.6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id gt10sm7709777wib.20.2015.06.17.06.21.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 06:21:32 -0700 (PDT) Message-ID: <55817458.5020104@6wind.com> Date: Wed, 17 Jun 2015 15:21:28 +0200 From: Vincent JARDIN Organization: www.6wind.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Panu Matilainen , Neil Horman , Thomas Monjalon References: <9092314.MoyqUJ5VU2@xps13> <20150617103521.GB24677@hmsreliant.think-freely.org> <55816489.5080706@redhat.com> In-Reply-To: <55816489.5080706@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 13:21:34 -0000 On 17/06/2015 14:14, Panu Matilainen wrote: > (initially accidentally sent to announce, resending to dev) > > On 06/17/2015 01:35 PM, Neil Horman wrote: >> On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote: >>> Hi all, >>> >>> Sometimes there are some important discussions about architecture or >>> design >>> which require opinions from several developers. Unfortunately, we cannot >>> read every threads. Maybe that using the announce mailing list will help >>> to bring more audience to these discussions. >>> Please note that >>> - the announce@ ML is moderated to keep a low traffic, >>> - every announce email is forwarded to dev@ ML. >>> In case you want to reply to this email, please use dev@dpdk.org >>> address. >>> >>> 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 >>> >>> 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. >>> http://dpdk.org/doc/guides-2.0/rel_notes/abi.html >>> There were some interesting discussions but not a lot of participants: >>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=8461 >>> >>> >>> During the current development cycle for the release 2.1, the ABI >>> question >>> arises many times in different threads. >>> To add the hash key size field, it is proposed to use a struct >>> padding gap: >>> http://dpdk.org/ml/archives/dev/2015-June/019386.html >>> To support the flow director for VF, there is no proposal yet: >>> http://dpdk.org/ml/archives/dev/2015-June/019343.html >>> To add the speed capability, it is proposed to break ABI in the >>> release 2.2: >>> http://dpdk.org/ml/archives/dev/2015-June/019225.html >>> To support vhost-user multiqueues, it is proposed to break ABI in 2.2: >>> http://dpdk.org/ml/archives/dev/2015-June/019443.html >>> To add the interrupt mode, it is proposed to add a build-time option >>> CONFIG_RTE_EAL_RX_INTR to switch between compatible and ABI breaking >>> binary: >>> http://dpdk.org/ml/archives/dev/2015-June/018947.html >>> To add the packet type, there is a proposal to add a build-time option >>> CONFIG_RTE_NEXT_ABI common to every ABI breaking features: >>> http://dpdk.org/ml/archives/dev/2015-June/019172.html >>> We must also better document how to remove a deprecated ABI: >>> http://dpdk.org/ml/archives/dev/2015-June/019465.html >>> The ABI compatibility is a new constraint and we need to better >>> understand >>> what it means and how to proceed. Even the macros are not yet well >>> documented: >>> http://dpdk.org/ml/archives/dev/2015-June/019357.html >>> >>> Thanks for your attention and your participation in these important >>> choices. >>> >> >> Thomas- >> Just to re-iterate what you said earlier, and what was discussed >> in the >> previous ABI discussions >> >> 1) ABI stability was introduced to promote DPDK's ability to be >> included with >> various linux and BSD distributions. Distributions, by and large, favor >> building libraries as DSO's, favoring security and updatability in >> favor of all >> out performance. >> >> 2) The desire was to put DPDK developers in a mindset whereby ABI >> stability was >> something they needed to think about during development, as the DPDK >> exposes >> many data structures and instances that cannot be changed without >> breaking ABI >> >> 3) The versioning mechanism was introduced to allow for backward >> compatibility >> during periods in which we needed to support both an old an new ABI >> >> 4) As Stephan and others point out, its not expected that we will >> always be able >> to maintain ABI, and as such an easy library versioning mechanism was >> introduced >> to prevent the loading of an incompatible library with an older >> application >> >> 5) The ABI policy was introduced to create a method by which new ABI >> facets >> could be scheduled while allowing distros to prepare their downstream >> users for >> the upcomming changes. >> >> >> It seems to me, looking back over these last few months, that we're >> falling down >> a bit on our use of (3). I've seen several people take advantage of >> the ABI >> scheduled updates, but no one has tried the versioning interface, and >> as a >> result patches are getting delayed, which was never my intent. Not >> sure whats >> to be done about that, but we should probably address it. Is use of the >> versionnig interface just too hard or convoluted? > > To me it seems that by far the biggest problem with ABI stability in > DPDK is features requiring changes to public structs (often directly > allocated and accessed by apps), which is something the symbol > versioning doesn't directly help with, you'd need to version the structs > too. > > One only needs to glance at the glibc documentation on how to accomplish > it [1] to see it gets rather involved. Glibc promises backwards > compatibility for life, so the effort is justified. However in where > DPDK we're talking about extending compatibility for a few months by > minimum requirement, people are unlikely to bother. > > [1] https://sourceware.org/glibc/wiki/Development/Versioning_A_Structure Does it means that it requires a specific engineering so we are back to the needs of using two layers: a- the direct calls to "non ABI stable layers" (current librte*) for those we can/are fine to use it, b- the calls thru such layers that guarantee the ABI stabilities (a librte_compat?) for those who needs it. Could both be exposed by the distributions so they can be consumed? Thank you, Vincent