From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id B18B12A5F for ; Sun, 22 Nov 2015 22:00:56 +0100 (CET) Received: by wmec201 with SMTP id c201so135948896wme.0 for ; Sun, 22 Nov 2015 13:00:56 -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=5DPk4mE1AqEE51yRMaVi93DcT03WvObLDmsstBR3l5A=; b=jN5eK8lP+RqKZxd+b6JSKiK3G0APJ2nOQGvVEnojaCixkl3UeuwGArGYw7rxYH5ddS FRsSS2yItr3Q1g2RCahTB958Ot3krPFk9Iwv8XiWDKLVXlTogZbc++p+GCuPgYzw4jmw 1H7rmClO6mi3QhZ/ZdljRHUIO8VwgieALmHtdavFppNDyVG0xoA6d57Ol6VYwLRVUMmA zDv13bZa/UfkRjEUG6EEu7h4M1OrnytPD5cqZnzHezXYn+lLET6myzB1HcgyijAAbSLH O5R+pNErql1mOGlkwaKt/X0p0Yjxbd2uQqsbKosbUSEWU+tzbsQyMiRZk9kBCXgTFtt+ ZWbQ== 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=5DPk4mE1AqEE51yRMaVi93DcT03WvObLDmsstBR3l5A=; b=EbZ2PMiPoQlFuR11wJFrupBFuM2n2Rn6PG15nKw0pdoVJih7c3FE2Co0cd4IEjDGd9 11ymIAWZGwicpxxZiv7TG6FYbGFEJebSeMolMBo+JYVRzvFmOaHzdlnPgjfbzVRFRkNg dTrUlqlfRJsnVNsJQLGvKX8tr+tnsSZ5pxq0/Roed8NZLT8wNFCyutWQ9b4UEI0sLub4 0GV9DzNSZ9Odkk7fZyqdjf0A7o7pU60lh5kEPobvxBmR+3JnSz2WU52Od5aVmmx/Wpbl EHFUwFhsE+lLVAkg0r75qBTY+VsleIEoTToAxTLBGn39ZyVWviysu8UlCjsRaZOBXDGf mbfg== X-Gm-Message-State: ALoCoQnmrHtxlmFYANv9bJSZS+sMDtNhksN37IS3XOdv4uelbf2DYXCyl3Z84WzMy43kBeDZs7yY X-Received: by 10.28.184.13 with SMTP id i13mr11699466wmf.31.1448226056454; Sun, 22 Nov 2015 13:00:56 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id a186sm10000504wmh.4.2015.11.22.13.00.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Nov 2015 13:00:55 -0800 (PST) From: Thomas Monjalon To: Matthew Hall Date: Sun, 22 Nov 2015 21:59:30 +0100 Message-ID: <2764108.ZoWOrsZgTX@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20151122002518.GA7196@mhcomputing.net> References: <20151121084935.GA24056@mhcomputing.net> <2295250.tyqBLnBnCL@xps13> <20151122002518.GA7196@mhcomputing.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] difficulty w/ RTE_NEXT_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: Sun, 22 Nov 2015 21:00:56 -0000 2015-11-21 19:25, Matthew Hall: > On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote: > > The new mbuf provides packet type instead of flags. > > So the processing in this function is changed and the variable name is > > different to reflect this. > > But the data type of the variable is the same, and this is an internal > always_inline function. It is an example application using a mbuf feature which changes depending of CONFIG_RTE_NEXT_ABI. The ABI is in the mbuf library not in the app. The header of the app function is changed only for the variable name because the semantic is changed. > So again I am confused what advantage we got from RTE_NEXT_ABI here, and how > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a > binary variable. I don't understand what is not clear here. > This doesn't really answer the bigger question about the reasoning. Probably because you don't ask clearly your question. Please check the code and your question again. Maybe that this reading may help: doc/guides/contributing/versioning.rst