From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 05A162EDA for ; Fri, 27 Nov 2015 14:31:22 +0100 (CET) Received: by wmww144 with SMTP id w144so58496951wmw.0 for ; Fri, 27 Nov 2015 05:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=BQI4Xtsu1PLXhVQvnzWIakDvgzM9q0deJ0IUFlILIkQ=; b=Ei30oB+O1EDdftQa2eB6RkAF2uVKhhgzQJB9IN1HgPmo+xnT+Or7UqIxR7ieZ4RdoP jcXV2xAS1r8m+L/74YaWype/FiIpuNkEvBq7EKj0RJd7nVwgb0seCjShPEk905fMVBC0 E2FaRHey0DpSexlL9mrEA3aEEt2cDPsWWHMtAHfiB0VFV6Xg+E3pYblQlMeKgdgOd7nB qOUoTkQJotaQjahBnKS+HVt5NW/Nfo30Jx1VaILqlZf2bTRUsYkfASR7NlQqihySwufY o9MSIt/MnwubztzyG/DSrswAvMHRr640wJ0vsHzzxdPvuC5lvzUXEBuCYW4Jif8PLAhZ 9wjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=BQI4Xtsu1PLXhVQvnzWIakDvgzM9q0deJ0IUFlILIkQ=; b=WdYIfBa/KtUpuFTP1yejRAY1p/IOnWBwv7zI6UccP+h4KZkNcc1yuu7sJKD8IC8wyv 68LnuWOg1dNEW313DMcSLwbWW3OJEruKFa5geeG24sDZ9EIiksUilhp+cDqPoaznXuK5 JhalUWR0fPRemftFwsXB40zp01H+rH3/YwUegI5Vpi29gMWeH62WjkOHxKN2XvYQDAZi CQYpKK/gwWJv0b5EMDbd3RI1oEoYv/8kLxPcbC1i6K9uIC+MFWhgCiIlo6Df6USSNjwC CBt0+xJN3OKKck1Av1RgjHkaizgYOVUFjC+Mydd0JImR1DSvLDdCQvM4trGQtT+9vFN2 A/9A== X-Gm-Message-State: ALoCoQnTFKHOjY887jd28myjPsbzK8Dizf6nq9A4ZuUN0j3Iy1NnDkYLT5PGgXfuEEaTKCXbRa39 X-Received: by 10.28.229.15 with SMTP id c15mr11096683wmh.76.1448631081728; Fri, 27 Nov 2015 05:31:21 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id o65sm7562370wmg.3.2015.11.27.05.31.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Nov 2015 05:31:21 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Fri, 27 Nov 2015 14:30:02 +0100 Message-ID: <7197986.Uky0E0JuXH@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56585604.9030909@redhat.com> References: <1448473135-19604-1-git-send-email-thomas.monjalon@6wind.com> <345C63BAECC1AD42A2EC8C63AFFC3ADC2809A787@irsmsx105.ger.corp.intel.com> <56585604.9030909@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state 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: Fri, 27 Nov 2015 13:31:22 -0000 2015-11-27 15:09, Panu Matilainen: > On 11/26/2015 03:51 PM, Doherty, Declan wrote: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > >> 2015-11-26 10:00, Panu Matilainen: > >>> On 11/26/2015 09:39 AM, Panu Matilainen wrote: > >>>> I think an experimental library which declares itself exempt from the > >>>> ABI policy should not be compiled by default. That way anybody wanting > >>>> to try it out will be forced to notice the experimental status. > >>>> > >>>> More generally / longer term, perhaps there should be a > >>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and > >>>> defaults to off. > >>> > >>> On a related note, librte_mbuf_offload cannot be built if > >>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at > >>> least currently) so tightly couple to cryptodev that perhaps it too > >>> should be marked experimental and default to off. > >> > >> I think you are right. > >> Declan, what is your opinion? > > > > > > Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's > > probably one of the areas which will most likely change in the future. > > > > On the issue of turning off experimental libraries in the build by default, my > > preference would be not to turn them off unless the library has external > > dependencies, otherwise the possibility of patches being submitted which > > could break an experimental library will be much higher. In my opinion the > > fewer build configurations developers have to test against the better. > > What I'm more worried about is users and developers starting to rely on > it while still in experimental state, a single comment in the header is > really easy to miss. There are some comments in the config, the header file, doxygen and the release notes. When using a feature, you have to read the header or the doc. So would it be better advertised by adding a comment in the doxygen section of some of the mandatory functions or structures? > So I'd like to see *some* mechanism which forces users and developers to > acknowledge the fact that they're dealing with experimental work. > Defaulting to off is one possibility, another one would be wrapping > experimental APIs behind a define which you have to set to be able to > use the API, eg: > > #if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES) > [...] > #endif Are you sure about the babies? ;)