From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id 7E5D6C364 for ; Wed, 17 Jun 2015 01:30:47 +0200 (CEST) Received: by wifx6 with SMTP id x6so34975559wif.0 for ; Tue, 16 Jun 2015 16:30:47 -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:subject:date:message-id:organization :user-agent:mime-version:content-transfer-encoding:content-type; bh=xORZ05aGQrov55zTLZEh7f6iE3+nbnGK6Nc75+gtbJ0=; b=N+4eBmtC8NP/Vynbox8GD8IbacoarFPtfmlCvPyavBXQ1haqCawAoXrZBhP4OK1nqc Df2kiu5TdCchX/iunyEUVa3JfCYQRzJebIojoQ99ZmnYSG+bY2+tzEpfnCsqELr+Y3yh W1Szrg80np0DNJqPDmijdKIYynbec6Qd+wAvDqydLTcoobiym6Sf2t67hfm5WqQ87jfG op8ffY0SqenSzxWMni6+rLpopu26Xa1fE7tD7MkW1yLWLeqxVrlmeK4VV/oUXhwUHIHM Z3kdWCuliAOBI3tKQh2RVp9W1J99EUUChCxUl4INKAhrjBQEo7to21BO37bKRr/7gz1y uiZw== X-Gm-Message-State: ALoCoQl+ZWC4xaFZP2+PiRIYlst7IFG75RnUSZmkwSRox0WiwNAYz2/PKvHuCjAA01I1wXcLRU/l X-Received: by 10.180.109.226 with SMTP id hv2mr11835569wib.64.1434497447386; Tue, 16 Jun 2015 16:30:47 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ei8sm3896101wjd.32.2015.06.16.16.30.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 16:30:46 -0700 (PDT) From: Thomas Monjalon To: announce@dpdk.org Date: Wed, 17 Jun 2015 01:29:47 +0200 Message-ID: <9092314.MoyqUJ5VU2@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-announce] important design choices - statistics - ABI X-BeenThere: announce@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK release announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 23:30:47 -0000 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.