From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id DFF7E1B36A for ; Mon, 5 Feb 2018 15:16:24 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 988DD20CB0; Mon, 5 Feb 2018 09:16:24 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 05 Feb 2018 09:16:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=mukfZKpCrw4a2xhWyH3mMA8z35 IcGrB5jZn/p+GMYKY=; b=FqoYKysrDMP2z55YFK01iJ37EqLrHQIqvbCmB2RVmz 7euCmOrw8u5jJ/5wXJNF92QOhjHcy1SeK7bb9HcUUJjkgKLe2OI8a2MMzaJzFgAs uDAoEt4vQMcewlxTYzAEv3E4K7CFqf8AK62jyhtE8zlPRykALsXmGxRDH3C08n5l c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=mukfZK pCrw4a2xhWyH3mMA8z35IcGrB5jZn/p+GMYKY=; b=bDdprEIS+9G2FrUf3mo087 se5Xm00fwgc0o1c5r2aTrdsRjraVLmWKzE/AOt27StKMblr0EXvn1CV/2ZVZNt7E wcqbA+1KGeZg0GcGeRiJTpNAJcatwwjIMDgxJyfLUQlG6BefOuFC8rS7m1ihRkMH el18E7mCaU+tB1zbXzMPIXNIozA7eB/MYlpB50tm2sZg0Ol1ew/ijXGKF28G1Jms V5JU6EkkFLeYbmci6CmHIYn9y99U4gumw/pX8odq0XEql55V+MteoWDDXaUapfxy y6E+bsIpbTDkYRjPc5WjpEolVcUA4XwQzwJT/J+YCw9iekkoYI/5ZxftIhMS4ZPw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3498B240B6; Mon, 5 Feb 2018 09:16:24 -0500 (EST) From: Thomas Monjalon To: Adrien Mazarguil Cc: Marcelo Ricardo Leitner , "Van Haaren, Harry" , "dev@dpdk.org" , Shahaf Shuler , Nelio Laranjeiro Date: Mon, 05 Feb 2018 15:16:21 +0100 Message-ID: <1992025.8JADqR79Gx@xps> In-Reply-To: <20180205134446.GG4256@6wind.com> References: <20180202144736.8239-1-adrien.mazarguil@6wind.com> <20180205125806.GE27676@localhost.localdomain> <20180205134446.GG4256@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 3/4] net/mlx: version rdma-core glue libraries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 14:16:25 -0000 05/02/2018 14:44, Adrien Mazarguil: > On Mon, Feb 05, 2018 at 10:58:06AM -0200, Marcelo Ricardo Leitner wrote: > > On Mon, Feb 05, 2018 at 12:24:23PM +0000, Van Haaren, Harry wrote: > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marcelo Ricardo Leitner > > > > Sent: Monday, February 5, 2018 12:14 PM > > > > To: Adrien Mazarguil > > > > Cc: Thomas Monjalon ; dev@dpdk.org; Shahaf Shuler > > > > ; Nelio Laranjeiro > > > > Subject: Re: [dpdk-dev] [PATCH v2 3/4] net/mlx: version rdma-core glue > > > > libraries > > > > > > > > On Mon, Feb 05, 2018 at 12:24:02PM +0100, Adrien Mazarguil wrote: > > > > > On Sun, Feb 04, 2018 at 03:29:38PM +0100, Thomas Monjalon wrote: > > > > > > 02/02/2018 17:46, Adrien Mazarguil: > > > > > > > --- a/drivers/net/mlx4/Makefile > > > > > > > +++ b/drivers/net/mlx4/Makefile > > > > > > > @@ -33,7 +33,9 @@ include $(RTE_SDK)/mk/rte.vars.mk > > > > > > > > > > > > > > # Library name. > > > > > > > LIB = librte_pmd_mlx4.a > > > > > > > -LIB_GLUE = librte_pmd_mlx4_glue.so > > > > > > > +LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION) > > > > > > > +LIB_GLUE_BASE = librte_pmd_mlx4_glue.so > > > > > > > +LIB_GLUE_VERSION = 18.02.1 > > > > > > > > > > > > You should use the version number of the release, i.e. 18.02.0 > > > > > > Ideally, you should retrieve it from rte_version.h. > > > > > > > > > > Keep in mind this only needs to be updated when the glue API gets > > > > modified, > > > > > and this "18.02.1" string may remain unmodified for subsequent DPDK > > > > > releases, probably as long as the PMD doesn't use any new rdma-core calls. > > > > > > > > > > We've already backported this patch to 17.02 and 17.11, both requiring > > > > > different sets of Verbs calls and thus a different version, hence the > > > > added > > > > > "18.02" as a starting point. The last digit may have to be modified > > > > possibly > > > > > several times between official DPDK releases while work is being done on > > > > the > > > > > PMD (i.e. per commit). > > > > > > > > > > In short it's not meant to follow DPDK's public versioning scheme. If you > > > > > really think it should, doing so will make things more complex in the > > > > > Makefile, which will have to parse rte_version.h. What's your opinion? > > > > > > > > What about appending date +%s output to it? It would be stricter and > > > > automated. > > > > > > Adding current timestamp or date into a build breaks reproducibility of builds, so is > > > generally not recommended. > > > > Then the sha1sum of mlx4_glue.h. > > With this the size check I mentioned on the other patch would become > > redundant and unnecessary. > > Using a strong hash algorithm to version a library/symbol, while possible, > seems a bit overkill and results in ugliness: > > librte_pmd_mlx4.so.c4ca4eaf2fe975ead83453458f4f56db49e724f3 > > Using a weak one like CRC32 for a shorter name poses a risk of > collision. Moreover the next time someone decides to update all version > notices or modify a comment will impact that hash. We'd need to isolate the > symbol definition itself, ignore parameter names in function prototypes and > only then we may get a somewhat meaningful hash describing a given ABI. > > Given the added complexity, is there really a problem with simple version > numbers we increment every time something gets modified? (Note this is > already how our .map files work, they're not generated automatically) Our map files show the major version where a symbol was introduced. It is simple because no symbol can be introduced in a minor version. > How about keeping things as is? You are using 18.02.1 while it is introduced in 18.02.0. If you don't want to correlate the .so version number with DPDK version number, maybe that 1, 2, 3 would be a simpler choice (less confusing).