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 BD6BC4590E; Thu, 5 Sep 2024 16:02:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87BD942E6E; Thu, 5 Sep 2024 16:02:21 +0200 (CEST) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by mails.dpdk.org (Postfix) with ESMTP id 48C92427E7 for ; Thu, 5 Sep 2024 16:02:20 +0200 (CEST) Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-456954d0396so4834961cf.3 for ; Thu, 05 Sep 2024 07:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725544939; x=1726149739; 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=ZY0mq3eq6ncU6kQnp0p/3TXQ4Wb4RCQCl7QSPltnvho=; b=DO/nR+Z5zwOacxATKbV07+7MwG/H0DqaEgfvrCtLwf1dkqTi/AQ81JmwtOWMU1xsAF QvBF9G11WmaIyOuS0OznUFQf88p7qGmnI+g6q2ewQMk5Y3n0vx8YNMrMudbRoAxjwi7i yDScyCElrxGRPHM4WhSAT2QkZotol1BLaLQoKQiO9yy4GX4cpOXB0D+sHfh9TAwg3Eoi WhCb7VJHc0HZQsXoOxccparH52eiaPhZCjiiXy9PvY2SpE6qze/JV9rxgQvctM04pDWq /e7+9BJ1licwXFaJ3ArSaWlJSXU4F78JmNhCKlAA2oxPNH1TjQaJf6YlQPOMaYf0Kww4 IVTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725544939; x=1726149739; 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=ZY0mq3eq6ncU6kQnp0p/3TXQ4Wb4RCQCl7QSPltnvho=; b=pht/bhV8nV2TGQJGWiX0qbYqkBveng7gH5H6lUr3bicDvasrdoKRC2fcHsxMWi+KZy umS4rQoH7CzsPOlqPZvznpf1rTDaNy5gKNY+cay04uGr24yeXNfVzj6EvZwlvpciX/F3 NisZh8wTx2UoRQGmFM0EMcdUf95nWv69cKn3F8HvKYlBZxoyolmz/LbDPAakH+rpGLjP twdTLugFgw/wUBhb7WdU81nr86tOvnev5FnB+Ygyjmlv5nycqLGTdi7zUd+5uP0E1n4q wIDJaB/l1Ej/6nPm924JAOlIJ6nR1h5Da4/zztG3dWEkeTgMpdeB1P1F8v5xv0+h87pu pg8A== X-Forwarded-Encrypted: i=1; AJvYcCUJ4yRd5HJvgPyz8X5kd+TfFzyFeu5CBeDUM+Z8mJZswrejELXoLCPv4FAuzTgiYhlekHs=@dpdk.org X-Gm-Message-State: AOJu0YyK2TIXNk2vapdBpTOph78ZDoMy9ngveRrpAUS9nGAZmyBEzbhm sTLUMLPojo894iyGKcWhXnGhTVtA5AZBncosw4zfxlW+VSev8tIXDzIlCBFZ83iKqnbLOwD0Cub QgEpZ93KwrOjthkl/ndVFKBdWPkY= X-Google-Smtp-Source: AGHT+IHfND0aO7/oMXlZN8EFi5wtGy9Wc57JeaPrLQNTBw3Ye+iiYToROPK7EFSq4W0K5XoXhXIG3hTvrBwL3Cu6UEc= X-Received: by 2002:a05:622a:4119:b0:44f:ed67:655f with SMTP id d75a77b69052e-4571a01f367mr223906321cf.60.1725544939429; Thu, 05 Sep 2024 07:02:19 -0700 (PDT) MIME-Version: 1.0 References: <20240904180954.104473-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35E9F6A4@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F6A5@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6A5@smartserver.smartshare.dk> From: Jerin Jacob Date: Thu, 5 Sep 2024 19:31:51 +0530 Message-ID: Subject: Re: [PATCH 0/3] eal: mark API's as stable To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: 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 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 complex = change. > > > > > > > > On the trace API itself it should be ok. > > > > > > No! > > > > *sigh* > > > > > > > > Trace must remain experimental until controlled by a meson option, e.= g. > > "enable_trace", whereby trace can be completely disabled and omitted fr= om the > > 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. > > I cannot foresee if disabling trace at build time will require changes to= the trace API. So I'm being cautious here. > > However, if Jerin (as author of the trace subsystem) foresees that it wil= l be possible to disable trace at build time without affecting the trace AP= I, 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 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. > > Before doing that, rte_trace_mode_get/set() and the accompanying enum rte= _trace_mode should be changed to rte_trace_config_get/set() using a new str= uct rte_trace_config (containing the enum rte_trace_mode, and expandable wi= th new fields as the need arises). This will prepare for e.g. tracing to ot= her destinations than system memory, such as a remote trace collector on th= e network, like SYSLOG. > > > Patches welcome if you want it stripped. > > Don't have time myself, so I suggested it as a code challenge instead. :-= ) >