From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id C66B195D9 for ; Fri, 12 Feb 2016 16:40:26 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id c200so26168480wme.0 for ; Fri, 12 Feb 2016 07:40:26 -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=c60B5rdS62CuqFwXDZBUxntY2M6tLVF8BLGG6LecZpQ=; b=VDKZ734KQE69Jf/29pm6DFeC0CY6Ay3ANXfvUv5tjThkehGlbUgXAGEPq+4ze+Gzrx x6Kq4+nz+pzfg2+RsQ4KqEsW8gku5w2OQuEM+hXkhZShRolm4/uQfbZtTMq5aGYd6aHG EPoMDPW/Fetp2y0Xvcni6QhiSYNyJskeeL5fTQmnUbZbIQdqVR2sSbi4UfaBnvX0bayO nvHYlz2OtY3q9HXy0485QnaJVgOC9oJFc/INfMG2V6iRZhUHIC/ntxmsv6bZYWRMjwLb ZJ2rmJmVtv6MmpRfWu+6URo6PdETeZeh1OoKwfsCqo90J8ZhvZ9b7TPKIwKJ87GT1jAh XWQQ== 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=c60B5rdS62CuqFwXDZBUxntY2M6tLVF8BLGG6LecZpQ=; b=EMbViu6rGvPXV/3ry/Sm7kIbY1DxFeA+/HN8Fyd4yMNlV1HhFniOkpEy4krdXxvI3L kC5ZPDmynJGshZNvgTKg0w3eX7t42YA4GBp5k98s1JdJBviOsYl2liNvS7cbMMP6ll8w 5lnMicH/UkzWxk9StcRtAOirmMJLNjwdQtdH2TK4gm48ra0sckeR4zWRCQ47Bdj8ZoLi XURDbxdGVpZxAa8DV+Ohh5u6pHGJFyr65Wh/+I5nuxJxQJl8QmxTXL6LQjbFhT6Z6hwA DairI0HmYY1EFMmf4nyeTcAjdvn4L/5Ij2gWCaT1XpMin9AKOX8eCpIzFTXqtMCLEZnU 6klg== X-Gm-Message-State: AG10YOTT38HeXSyYr0xNpvjHGxDrrzDgRl7MlKn6CCSTJyb9NnsmIVMas+OCQxOs4Cp14rfc X-Received: by 10.28.19.204 with SMTP id 195mr5488681wmt.1.1455291626644; Fri, 12 Feb 2016 07:40:26 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id b1sm12614985wjy.0.2016.02.12.07.40.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 07:40:25 -0800 (PST) From: Thomas Monjalon To: "Wiles, Keith" Date: Fri, 12 Feb 2016 16:38:56 +0100 Message-ID: <10558998.3znIRhOpQL@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <09D5A01F-7205-49E8-9A27-95161235963E@intel.com> References: <1455039006-86816-1-git-send-email-keith.wiles@intel.com> <56BDEA08.9040402@redhat.com> <09D5A01F-7205-49E8-9A27-95161235963E@intel.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 v3] mempool: reduce rte_mempool structure size 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, 12 Feb 2016 15:40:27 -0000 2016-02-12 15:07, Wiles, Keith: > >On 02/12/2016 03:57 PM, Thomas Monjalon wrote: > >> 2016-02-12 13:23, Panu Matilainen: > >>> On 02/10/2016 11:18 PM, Keith Wiles wrote: > >>>> static inline void *rte_mempool_get_priv(struct rte_mempool *mp) > >>>> { > >>>> +#ifdef RTE_NEXT_ABI > >>>> + return (char *)mp + > >>>> + MEMPOOL_HEADER_SIZE(mp, mp->pg_num, mp->cache_size); > >>>> +#else > >>>> return (char *)mp + MEMPOOL_HEADER_SIZE(mp, mp->pg_num); > >>>> +#endif /* RTE_NEXT_ABI */ > >>>> } > >>> > >>> This is not RTE_NEXT_ABI material IMO, the added ifdef clutter is just > >>> too much. > >> > >> The changes are restricted to the mempool files. > >> I think it is not so much. However I wonder how much the feature is important > >> to justify the use of NEXT_ABI. > > > >Well yes, to be precise: for the benefit of this patch, the ifdef > >clutter seems too much. > > > >Its not as if every change is expected to go through a NEXT_ABI phase, > >based on http://dpdk.org/ml/archives/dev/2016-February/032866.html there > >might be some confusion regarding that. > > I think the NEXT_ABI is reasonable in this case as it does change a structure everyone uses and the ifdef clutter is caused by having to remove old ifdefs, which is a good thing for DPDK. The NEXT_ABI ifdefs only exist for one release and then they will disappear, which I think is more then reasonable. OK, I'm going to sum it up with new words and let the conclusion comes from Keith, Panu and Olivier. We agreed to allow ABI breaking if a notification was done in the previous release. Keith has sent a notification for 16.04 so the "official" ABI will be changed in 16.07. It is also encouraged to show how the ABI will be broken when sending a notification. It allows to give an informed opinion before ack'ing. The code snippet will also be useful to app developpers when preparing a future upgrade. Keith has sent the whole code change. This code change may be submitted in the current release without waiting the deprecation time if gated in the NEXT_ABI ifdefs. It allows to provide the feature to app developpers who don't care about versioning. But the price is a more complicated code to read and manage. To make it short, the rules to use NEXT_ABI are not strict and may change. So now you have to decide if this change can be integrated in 16.04 as NEXT_ABI.