From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Mon, 9 Sep 2024 06:48:46 +0200 (CEST) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e1a74ee4c0cso4238661276.2 for ; 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> <98CBD80474FA8B44BF855DF32C47DC35E9F6A4@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F6A5@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F6B0@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F6B9@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6B9@smartserver.smartshare.dk> From: Jerin Jacob Date: Mon, 9 Sep 2024 10:18:19 +0530 Message-ID: Subject: Re: [PATCH 0/3] eal: mark API's as stable To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Ferruh Yigit , David Marchand , Jerin Jacob Kollanukkaran , Stephen Hemminger , bruce.richardson@intel.com, Sunil Kumar Kori , dev@dpdk.org, Thomas Monjalon 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Sep 6, 2024 at 8:12=E2=80=AFPM Morten Br=C3=B8rup 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 > > >> 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 > > >>>>> 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 > > >>>>>>> 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. >