From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8CFD7A051A; Fri, 17 Jan 2020 11:46:11 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 620D31D445; Fri, 17 Jan 2020 11:46:11 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id E8FDB1D426; Fri, 17 Jan 2020 11:46:09 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id c9so22216682wrw.8; Fri, 17 Jan 2020 02:46:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=qsOhP0i1xH1yutLWxNnYRzT9uaDrlbnON5al3xsaEiE=; b=ObEwK6SoM/aD1IWwTWgS56zCTI8JzhC+VtL187dADJapD2D2VHkobVWv0gN2hdcF+1 uri4pchI0LKYE0MQYnOR9//4mLOn9hHL8dzCOH+JreA8B/mVkFsKMytuyPGKoHQ1BAsV YLHl4zT3EpFK5G/FmQ++gxLpnQtTBITN1excfTcCL2/fHqP7ruRb5VTX5DQoMWoj5T/x pcujlVGE+LGSm2ltSbTXhx0r7+mlpSO42hqhRqeogSSqSaeLKCo/TY1mlCyvDNy2gygX L7O3FGKC6g9inq9Ppt4HqKzw5GL80lfRT5aVljty2Cn3FJxLvV3CNPjlxh76/vVsbrL1 N0Gg== X-Gm-Message-State: APjAAAW+gYUGaPEu3ZWgYkMgxwXH+woShuzu7lX8VGveQnkipS3DFEvy UH5NUQF0VadNPzMQahoWhvOaCwSaAhkLGw== X-Google-Smtp-Source: APXvYqy4O+t9TbYBKcDPugpKIhyJ9tHyNZyYHjvSmOUOAkV5gJm8xax+zbw0jUDHxgHx+JLHtUaJeQ== X-Received: by 2002:adf:dfc2:: with SMTP id q2mr2445723wrn.251.1579257969609; Fri, 17 Jan 2020 02:46:09 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id t25sm8756936wmj.19.2020.01.17.02.46.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2020 02:46:08 -0800 (PST) Message-ID: <162745a0a36061f0f9a3a4cc7db860eb132eabac.camel@debian.org> From: Luca Boccassi To: David Marchand , Thomas Monjalon Cc: Neil Horman , Ferruh Yigit , Ray Kinsella , Cristian Dumitrescu , dpdk stable , dev , Eelco Chaudron , Kevin Traynor , Ian Stokes , Ilya Maximets Date: Fri, 17 Jan 2020 10:46:08 +0000 In-Reply-To: References: <20191217130742.165886.15691.stgit@netdev64> <20200116115458.GB3282@hmswarspite.think-freely.org> <6957820.jRhZ6ZUK3Y@xps> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] meter: move RFC4115 trTCM APIs as none experimental 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, 2020-01-17 at 09:27 +0100, David Marchand wrote: > On Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon < > thomas@monjalon.net > > wrote: > > 16/01/2020 13:42, Ferruh Yigit: > > > On 1/16/2020 11:54 AM, Neil Horman wrote: > > > > On Thu, Jan 16, 2020 at 12:25:06PM +0100, David Marchand wrote: > > > > > On Tue, Dec 17, 2019 at 2:08 PM Eelco Chaudron < > > > > > echaudro@redhat.com > > > > > > wrote: > > > > > > Moved RFC4115 APIs to none experimental as they have been > > > > > > there > > > > > > since 19.02. Also, these APIs are the same as the none > > > > > > RFC4115 APIs. > > > > > >=20 > > > > > > Signed-off-by: Eelco Chaudron < > > > > > > echaudro@redhat.com > > > > > > > > > > > >=20 > > > > > There is a discussion on the OVS ml at the moment to get > > > > > these symbols > > > > > in the stable ABI for 19.11. > > > > > I want to understand how this would be done. > > > > >=20 > > > > > - I take this patch in 20.02, these symbols are added in the > > > > > 20.0.1 ABI. > > > > > On the other hand, the 19.11 release maintains the 20.0 ABI. > > > > >=20 > > > > > Does it mean the backport adds these symbols with the 20.0 > > > > > version in > > > > > the 19.11 branch? > > > > > Or is 20.0.1 version acceptable / a thing we want? > >=20 > > We cannot have the symbol with different versions in different > > releases, > > otherwise the compatibility is broken when upgrading. > > So we have no choice, the symbol must have version 20.0.1 > > in release 19.11.1, as in release 20.02. >=20 > Indeed, good point. >=20 >=20 > > > > > - These symbol already existed in the 20.0 ABI, versioned as > > > > > EXPERIMENTAL. > > > > > We can go and remove these entries since we are not bound to > > > > > preserve > > > > > the experimental APIs. > > > > > But, on the other hand, nothing should prevent us from > > > > > keeping some > > > > > aliases so that the symbols versioned EXPERIMENTAL are still > > > > > available > > > > > to existing users. > > > > >=20 > > > >=20 > > > > I would say that choice is up to you. If you want to alias > > > > them to be nice to > > > > prior users, thats fine by me. But experimental means > > > > experimental, and so users > > > > have to be prepared to rebuild when things change, even if that > > > > change is > > > > changing the version from experimental to a concrete version. > > > >=20 > > >=20 > > > I would prefer to keep the alias and don't break the existing > > > users, specially > > > for the case experimental API is becoming mature without change. > >=20 > > I agree, it's cool to be nice :) >=20 > Luca, opinion? I'd not only prefer it but also go as far as require it for backporting to 19.11 - experimental means experimental, but stable means stable :-) --=20 Kind regards, Luca Boccassi