From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 805E445940; Mon, 9 Sep 2024 01:58:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0DEB5402A8; Mon, 9 Sep 2024 01:58:14 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 951E140294 for <dev@dpdk.org>; Mon, 9 Sep 2024 01:58:12 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2d8f06c2459so2409665a91.0 for <dev@dpdk.org>; Sun, 08 Sep 2024 16:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1725839891; x=1726444691; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=cCf4DyTivUyooqa5v6FtZkGsvnadX2yiS0hN4slJGFc=; b=uOuJYtxKSwhBQkPSaelygBM77LBm59vMhpyislxN6g43gfGcxegd/PYHrx01nPGL1C JVHZhz3w6xSeUrHm7r9kt48MFv1aoU6zIsrQsyUviyZLQ8nxE2iZd/k0JIlnBUQgeS7D cMob1sBk5Gb4OyyxyhWOSwGk3vurIMNRql/719+5Du3j0Xte23RznDA+uc8YD959DnQ4 IDTCdWff++3yobQjZJuuVK65HFHPyhhZPgIUyXX8M65EJqZRIag2f3rbvitzrfGBfyct yDf8F2kYCdILH6I7dpyD2Q+Sj2mNGStlavX6WM4YkQrGJFVu73E+ptqHFXjc2YPnCfrl 5nEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725839891; x=1726444691; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cCf4DyTivUyooqa5v6FtZkGsvnadX2yiS0hN4slJGFc=; b=nK9RQyeYYP1sjN/4/BOnCm6XSZ+phy/NH9GgUUmmyD9AGao//0KxfDNTuAHDuoahxH GZRdpDHQiZeeIODaXGkh1gW6WoLfuwyERqsZk82JKQ6ekZ8JxqfJC2DJuav4zbZIgq8u hRBcDzRKTnm4bBKZUVe+2pwp0xOX9XL8trXHPhAM+7EI4UaDSmIoFx7CeaBwDkf6oscv GK3YhyC+NkmDwtRgknA6p7+aoIAsPImPwZqUF8MSgeIvQloa/ujuEvUyEELYeFEjVGaJ 8oTNP+cyoLRsvwtQzHu+JvWgurA+YyimE4zVQzXjgydGOn/ONzOdTMe463qJ7O5cnPWa CmxQ== X-Forwarded-Encrypted: i=1; AJvYcCWDoeHLW1GTSd4anz799/f8UwJK+hJLvR4+h8M3XN7biouGJr/afH+esU2+VPcr70lG7XA=@dpdk.org X-Gm-Message-State: AOJu0Yw0gW0k58O0KA+D/WGLXMRtyh48S0/U+BIcT5J2tetnFmBc4CyA OZYH107me0a6HtGawmeZid3jkBGVVegchYBxzHLH0kkSkws+jn3iPQGCTO13juU= X-Google-Smtp-Source: AGHT+IF3D2A3g5I52/E3yn3+EUevuS91BLoLYcBKwMzrJA1YlzJjccQmfBxlzi0D3h3HTIKAWpnfIw== X-Received: by 2002:a17:90b:4a4e:b0:2d8:cd04:c8f0 with SMTP id 98e67ed59e1d1-2dad5136fa5mr7614733a91.39.1725839891155; Sun, 08 Sep 2024 16:58:11 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2db04136b4esm3228037a91.8.2024.09.08.16.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Sep 2024 16:58:10 -0700 (PDT) Date: Sun, 8 Sep 2024 16:58:00 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com> Cc: "Jerin Jacob" <jerinjacobk@gmail.com>, "David Marchand" <david.marchand@redhat.com>, "Jerin Jacob Kollanukkaran" <jerinj@marvell.com>, <bruce.richardson@intel.com>, "Sunil Kumar Kori" <skori@marvell.com>, <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net> Subject: Re: [PATCH 0/3] eal: mark API's as stable Message-ID: <20240908165800.672fffb2@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6A6@smartserver.smartshare.dk> References: <20240904180954.104473-1-stephen@networkplumber.org> <CAJFAV8x1E4mcLwoHUhB1C=R5wjXq0aY1TRXPjwUhH1oj8qGu_Q@mail.gmail.com> <98CBD80474FA8B44BF855DF32C47DC35E9F6A4@smartserver.smartshare.dk> <CAJFAV8x_eoFS3C5cjuMi9_QOfXAz9S5UbsAUiZSyfjP8mSFdJg@mail.gmail.com> <98CBD80474FA8B44BF855DF32C47DC35E9F6A5@smartserver.smartshare.dk> <CALBAE1O7k40nqiTDw1uY8mPbcHxtoRHS140O6mPcQEL4F4wvqQ@mail.gmail.com> <98CBD80474FA8B44BF855DF32C47DC35E9F6A6@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Thu, 5 Sep 2024 16:18:13 +0200 Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote: > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > Sent: Thursday, 5 September 2024 16.02 > >=20 > > On Thu, Sep 5, 2024 at 3:14=E2=80=AFPM Morten Br=C3=B8rup <mb@smartshar= esystems.com> wrote: =20 > > > =20 > > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > > Sent: Thursday, 5 September 2024 11.03 > > > > > > > > On Thu, Sep 5, 2024 at 10:55=E2=80=AFAM Morten Br=C3=B8rup <mb@smar= tsharesystems.com> > > > > wrote: =20 > > > > > =20 > > > > > > From: David Marchand [mailto:david.marchand@redhat.com] > > > > > > Sent: Thursday, 5 September 2024 09.59 > > > > > > > > > > > > On Wed, Sep 4, 2024 at 8:10=E2=80=AFPM Stephen Hemminger > > > > > > <stephen@networkplumber.org> wrote: =20 > > > > > > > > > > > > > > The API's in ethtool from before 23.11 should be marked stabl= e. =20 > > > > > > > > > > > > EAL* ? > > > > > > =20 > > > > > > > Should probably include the trace api's but that is more comp= lex =20 > > change. =20 > > > > > > > > > > > > On the trace API itself it should be ok. =20 > > > > > > > > > > No! =20 > > > > > > > > *sigh* > > > > =20 > > > > > > > > > > Trace must remain experimental until controlled by a meson option= , e.g. =20 > > > > "enable_trace", whereby trace can be completely disabled and omitte= d from =20 > > the =20 > > > > compiled application/libraries/drivers at build time. > > > > > > > > This seems unrelated to marking the API stable as regardless of the > > > > API state at the moment, this code is always present. =20 > > > > > > I cannot foresee if disabling trace at build time will require change= s to =20 > > the trace API. So I'm being cautious here. =20 > > > > > > However, if Jerin (as author of the trace subsystem) foresees that it= will =20 > > be possible to disable trace at build time without affecting the trace = API, I > > don't object to marking the trace API (or some of it) stable. > >=20 > > I don't for foresee any ABI changes when adding disabling trace > > compile time support. =20 >=20 > Based on Jerin's feedback, I'm retracting my objection. >=20 > > However, I don't understand why we need to do > > that. =20 >=20 > To reduce code size. > Relevant for embedded/memory-constrained systems. >=20 > > In the sense, fast path functions are already having an option > > to compile out. > > Slow path functions can be disabled at runtime at the cost of 1 cycle > > as instrumentation cost. Having said that, I don't have any concern > > about disabling trace as an option. =20 >=20 > Great. >=20 > >=20 > > =20 > > > > > > Before doing that, rte_trace_mode_get/set() and the accompanying enum= =20 > > rte_trace_mode should be changed to rte_trace_config_get/set() using a = new > > struct rte_trace_config (containing the enum rte_trace_mode, and expand= able > > with new fields as the need arises). This will prepare for e.g. tracing= to > > other destinations than system memory, such as a remote trace collector= on the > > network, like SYSLOG. =20 >=20 > I'm also retracting this precondition... >=20 > If the need for further trace configuration should ever arise, rte_trace_= config_get/set() can be added later. > And rte_trace_mode_get/set(), if not marked as experimental anymore, will= be kept for backwards compatibility. >=20 > > > =20 > > > > Patches welcome if you want it stripped. =20 > > > > > > Don't have time myself, so I suggested it as a code challenge instead= . :-) > > > =20 My feeling is that the the experimental flag is not intended as permanent "= get out of ABI compatiablity"