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 1597245943;
Mon, 9 Sep 2024 06:48:48 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id D53DC402BE;
Mon, 9 Sep 2024 06:48:47 +0200 (CEST)
Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com
[209.85.219.182])
by mails.dpdk.org (Postfix) with ESMTP id 2C799402A8
for <dev@dpdk.org>; Mon, 9 Sep 2024 06:48:46 +0200 (CEST)
Received: by mail-yb1-f182.google.com with SMTP id
3f1490d57ef6-e1a74ee4c0cso4238661276.2
for <dev@dpdk.org>; Sun, 08 Sep 2024 21:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1725857325; x=1726462125; darn=dpdk.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=aK4BUXQus5GH9Vcg1VowgbLXRPtJ05bvw8V9lsXwYIM=;
b=dZrls1BBlA833Ht9GRdHbBMtXGNj7jjtjCTSJzCy5f3AolUFhPrwTuq6OYHtI0wMfc
0GXyv2pyG9M6j96Y9IdCOiRauE/96zOQsnXCy8njFL72EBt7IxxlDCMWeaTsqKE/WGTX
S0nrysfhroWciWDpTWsXccY5K5A/cJ2oD8T356ToKabcFkt+wLaxg8r7R8SRzFeSQuTE
8BoiR0A90QGEeISDNuxnKO6O9fu/jsqKpwqlwVWTNR4sCo0iWtfm/ArqE2T3OEnIDB/r
9c3ke1qySW8Kd4iOv52yKbkt1KsqBgkSu/qY7+t8KoYJkS5QKuv3JxJmAKYdIk8PcPvI
ZSHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1725857325; x=1726462125;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=aK4BUXQus5GH9Vcg1VowgbLXRPtJ05bvw8V9lsXwYIM=;
b=Tz4F8ovEd01kfxv+3FXA91EHATSbg2MJhVOv9J8FcZDuXG5xZEZthvOypG7Ze8tfyE
XsT5DwZLDXPhLe83kaPxrmkpuiltF2bU91DD1XF7DeTBw328flErRrbNbwqMrzDPnIUz
WPqqLrJwbP4e7uNSAmpaGtvloTlgqsEEj1VnS6lX9GN2+Du+BfBR5BtvS489V6y2jQMf
bt16z99IZGhn/MrTGUF4QeWWuh3yD//gDOkDp1TLxy1AeDqPfCgE22RmER/sxIe5XD+v
uXrzJZ1gU36loR753fFG7TO3uJxgVuENLT2iEMubSiT2GNR72iAielJHzSyFUeL6uMh7
RDFg==
X-Forwarded-Encrypted: i=1;
AJvYcCWIwwlRpgfEaS+cDkCpZ45L/ot97Pzi3EPbtPuc7CP0gmtjS/1VKFEzy3ZKiJuShvYLGJk=@dpdk.org
X-Gm-Message-State: AOJu0YwFfYUlQnhlJjO8FrB6pS2B5Wx4OnZBcR8JSrLB/ViJLjIc8x7h
5eY58tzpzCAT2Wy7CcWbgFASoxiIWaFeM96ILDxtXXPsmjXztEz9A3owAapzGG2v6JguUo7VoB7
ZbKQiGBNVqYQFcieI2SPzy/wd4ws=
X-Google-Smtp-Source: AGHT+IGdk4ALOEMk94UfWgxPulEeGHwXTSU43bmEJazBB4E294QTkRKA+Bji5VL9IFgqlLCsGchmhG93qJxg40vwC8Y=
X-Received: by 2002:a05:6902:2611:b0:e1d:1fd9:9e7c with SMTP id
3f1490d57ef6-e1d348a1a67mr11590259276.6.1725857325313; Sun, 08 Sep 2024
21:48:45 -0700 (PDT)
MIME-Version: 1.0
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>
<f71f21a8-ffe0-4b53-b1e9-70dfc0c29f0c@amd.com>
<98CBD80474FA8B44BF855DF32C47DC35E9F6B0@smartserver.smartshare.dk>
<d619abac-623a-4717-9a73-78d765970d95@amd.com>
<98CBD80474FA8B44BF855DF32C47DC35E9F6B9@smartserver.smartshare.dk>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6B9@smartserver.smartshare.dk>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Mon, 9 Sep 2024 10:18:19 +0530
Message-ID: <CALBAE1MCW1zM15O2VjGG7VpDihf9ZBgzCFSA+0UcSeX9dhT7GA@mail.gmail.com>
Subject: Re: [PATCH 0/3] eal: mark API's as stable
To: =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
Cc: Ferruh Yigit <ferruh.yigit@amd.com>,
David Marchand <david.marchand@redhat.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Stephen Hemminger <stephen@networkplumber.org>,
bruce.richardson@intel.com, Sunil Kumar Kori <skori@marvell.com>, dev@dpdk.org,
Thomas Monjalon <thomas@monjalon.net>
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 Fri, Sep 6, 2024 at 8:12=E2=80=AFPM Morten Br=C3=B8rup <mb@smartsharesys=
tems.com> wrote:
>
> > From: Ferruh Yigit [mailto:ferruh.yigit@amd.com]
> > Sent: Friday, 6 September 2024 16.12
> >
> > On 9/6/2024 11:04 AM, Morten Br=C3=B8rup wrote:
> > >> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com]
> > >> Sent: Friday, 6 September 2024 10.54
> > >>
> > >> On 9/5/2024 3:01 PM, Jerin Jacob wrote:
> > >>> On Thu, Sep 5, 2024 at 3:14=E2=80=AFPM Morten Br=C3=B8rup <mb@smart=
sharesystems.com>
> > >> wrote:
> > >>>>
> > >>>>> 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@sm=
artsharesystems.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> 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:
> > >>>>>>>>
> > >>>>>>>> The API's in ethtool from before 23.11 should be marked stable=
.
> > >>>>>>>
> > >>>>>>> EAL* ?
> > >>>>>>>
> > >>>>>>>> Should probably include the trace api's but that is more compl=
ex
> > >> change.
> > >>>>>>>
> > >>>>>>> On the trace API itself it should be ok.
> > >>>>>>
> > >>>>>> No!
> > >>>>>
> > >>>>> *sigh*
> > >>>>>
> > >>>>>>
> > >>>>>> Trace must remain experimental until controlled by a meson optio=
n, e.g.
> > >>>>> "enable_trace", whereby trace can be completely disabled and omit=
ted
> > from
> > >> the
> > >>>>> compiled application/libraries/drivers at build time.
> > >>>>>
> > >>>>> This seems unrelated to marking the API stable as regardless of t=
he
> > >>>>> API state at the moment, this code is always present.
> > >>>>
> > >>>> I cannot foresee if disabling trace at build time will require cha=
nges to
> > >> the trace API. So I'm being cautious here.
> > >>>>
> > >>>> However, if Jerin (as author of the trace subsystem) foresees that=
it
> > will
> > >> be possible to disable trace at build time without affecting the tra=
ce API,
> > I
> > >> don't object to marking the trace API (or some of it) stable.
> > >>>
> > >>> I don't for foresee any ABI changes when adding disabling trace
> > >>> compile time support. However, I don't understand why we need to do
> > >>> that. In the sense, fast path functions are already having an optio=
n
> > >>> to compile out.
> > >>> Slow path functions can be disabled at runtime at the cost of 1 cyc=
le
> > >>> as instrumentation cost. Having said that, I don't have any concern
> > >>> about disabling trace as an option.
> > >>>
> > >>
> > >> I agree with Jerin, I don't see motivation to disable slow path trac=
es
> > >> when they can be disabled in runtime.
> > >> And fast path traces already have compile flag to disable them.
> > >>
> > >> Build time configurations in long term has problems too, so I am for=
not
> > >> using them unless we don't have to.
> > >
> > > For some use cases, trace is dead code, and should be omitted.
> > > You don't want dead code in production systems.
> > >
> > > Please remember that DPDK is also being used in highly optimized embe=
dded
> > systems, hardware appliances and other systems where memory is not abun=
dant.
> > >
> > > DPDK is not only for cloud and distros. ;-)
> > >
> > > The CI only tests DPDK with a build time configuration expected to be=
usable
> > for distros.
> > > I'm not asking to change that.
> > > I'm only asking for more build time configurability to support other =
use
> > cases.
> > >
> >
> > I see, but that build time configuration argument exists in multiple
> > aspects. And with meson switch we lean to dynamic configuration approac=
h.
>
> It can be rte_config.h instead of Meson option. Either is perfectly fine =
with me.
>
> >
> > When a build time config introduced, again and again we are having case=
s
> > that specific code enabled with compile time macro broken and nobody
> > noticed.
>
> I acknowledge this risk.
if we use
if (0)
{
}
scheme instead of #ifdef scheme.
The compiler will check this leg even it is not active.
>
> Trace doesn't interact with anything, so I consider the risk extremely lo=
w in this case.
>
> > Having code enabled always and configured in runtime produces more
> > robust deliverable.
>
> The same can be said about the Linux kernel, but yet it is configurable.
>
> >
> > We are aware that DPDK is used in embedded device, but they are not
> > mostly very resource restricted devices, is it really matter to have a
> > few megabytes (I didn't check but I expect this the max binary size can
> > increase with tracing code) larger DPDK binary, does it really makes an=
y
> > difference?
>
> Code size also affects system boot time, because those superfluous megaby=
tes take time to decompress when booting from FLASH memory.
> For reference, the size of our system image (including Linux kernel, Open=
SSL, the DPDK application, webserver, GUI, CLI, SNMP and everything) is 12 =
MB compressed.
>
> From a security aspect, trace also increases the attack surface and can p=
otentially assist a hacker trying to break into a system.
>