From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98BD6C33CB1 for ; Fri, 17 Jan 2020 08:28:02 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 33DF320728 for ; Fri, 17 Jan 2020 08:28:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ecfJJhC/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33DF320728 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 366391D16D; Fri, 17 Jan 2020 09:28:01 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id B2F341D16C for ; Fri, 17 Jan 2020 09:27:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579249679; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+E5ouEzdZL2C4KkCWvwK/sPHuLTmJ2YyLHFNazgxYqQ=; b=ecfJJhC/WDe9tpHUZiKAM/sSVWwrLOIEw6hMKdRzgUy7YQgdXSAwUB9ICownjdMAR9w1fL BU4OlKeSaH3rtgNsJvbZW6aJZjVGanETaOqlib0BbQek8rm/3jSoV6W/opdr2vjEvXshlA PbizhvzZ29USjMTFukvbx/gqqQYVVG8= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-202-dgBifr-zO1m3-0A4yDKDsA-1; Fri, 17 Jan 2020 03:27:57 -0500 Received: by mail-vk1-f200.google.com with SMTP id m72so9406163vka.20 for ; Fri, 17 Jan 2020 00:27:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gN21rTrG+G1wXqM5Yio3TNDnO3RMD2GivIhuCQypx0=; b=mRSedBizlUBNGC4VjNnGQAlcw+O15KBBSIvR/sDcaUvjrTviLSiI2xWHNksiR9Uwlg 4HRnkGzN9RJyTEllGnk8ZomMzUsG+Qj4qrigyNbs+IU2+JuNMBhN7EZxSbwEnJQLn/M2 +ferPQhyqGEwkmQ5WA4OMTgYqHfvQ5LGJU0cEJ6dx629iqXY1z1BQz0udjDxFLlESdk1 RVMzibf2rCg26PeMrlhQDOinZWgF8g88sJtXB5/vOLwBPKT3dToCkpQl510lGLvTO3zQ UH2JGxkaOfqqEojrwg+GpYpx/N2hgfmBzNrfN0Q5w9CwogiqPtrhGVPwbf1KEK5pyBk6 wb8w== X-Gm-Message-State: APjAAAVFPsJMwENi+MBdDwbTykcol9lZwKo1ZyOi6kU8T4zW3xGTqyoN nsvpcC2mSRa6sXTR/GwzryxmD6amOznZatsvoJ8JIsIETQuMuPqs4G2IlxVelQDo/UOvUlkrUJt QEYNJb9M/WZqueXg2dvE= X-Received: by 2002:a67:e342:: with SMTP id s2mr4062009vsm.198.1579249676697; Fri, 17 Jan 2020 00:27:56 -0800 (PST) X-Google-Smtp-Source: APXvYqxDP6iEu/kg5285Ax7lZHw9cJq/XBbCK8PhmF1EpxlMMCPkCohheVWpjZSh030A0YVMn9RKetu0XKxKCEqvaCg= X-Received: by 2002:a67:e342:: with SMTP id s2mr4061998vsm.198.1579249676415; Fri, 17 Jan 2020 00:27:56 -0800 (PST) MIME-Version: 1.0 References: <20191217130742.165886.15691.stgit@netdev64> <20200116115458.GB3282@hmswarspite.think-freely.org> <6957820.jRhZ6ZUK3Y@xps> In-Reply-To: <6957820.jRhZ6ZUK3Y@xps> From: David Marchand Date: Fri, 17 Jan 2020 09:27:45 +0100 Message-ID: To: Thomas Monjalon , Luca Boccassi Cc: Neil Horman , Ferruh Yigit , Ray Kinsella , Cristian Dumitrescu , dpdk stable , dev , Eelco Chaudron , Kevin Traynor , Ian Stokes , Ilya Maximets X-MC-Unique: dgBifr-zO1m3-0A4yDKDsA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Jan 16, 2020 at 3:38 PM Thomas Monjalon 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 = 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= . > > >>> > > >>> Signed-off-by: Eelco Chaudron > > >> > > >> There is a discussion on the OVS ml at the moment to get these symbo= ls > > >> in the stable ABI for 19.11. > > >> I want to understand how this would be done. > > >> > > >> - 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. > > >> > > >> Does it mean the backport adds these symbols with the 20.0 version i= n > > >> the 19.11 branch? > > >> Or is 20.0.1 version acceptable / a thing we want? > > 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. Indeed, good point. > > >> - These symbol already existed in the 20.0 ABI, versioned as EXPERIM= ENTAL. > > >> We can go and remove these entries since we are not bound to preserv= e > > >> the experimental APIs. > > >> But, on the other hand, nothing should prevent us from keeping some > > >> aliases so that the symbols versioned EXPERIMENTAL are still availab= le > > >> to existing users. > > >> > > > I would say that choice is up to you. If you want to alias them to b= e nice to > > > prior users, thats fine by me. But experimental means experimental, a= nd so users > > > have to be prepared to rebuild when things change, even if that chang= e is > > > changing the version from experimental to a concrete version. > > > > > > > I would prefer to keep the alias and don't break the existing users, sp= ecially > > for the case experimental API is becoming mature without change. > > I agree, it's cool to be nice :) Luca, opinion? --=20 David Marchand