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 62B38A034C; Sat, 20 Aug 2022 17:19:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F15FF41109; Sat, 20 Aug 2022 17:19:44 +0200 (CEST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by mails.dpdk.org (Postfix) with ESMTP id 8B29240A80 for ; Sat, 20 Aug 2022 17:19:43 +0200 (CEST) Received: by mail-lf1-f51.google.com with SMTP id z6so9670067lfu.9 for ; Sat, 20 Aug 2022 08:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc; bh=cpH51Jlw2DMsRHspgboLmcc1an/7c473Q+RCXV6FNLE=; b=gFjE5BRItMQjqarB9z+cPWp6zs+oo/bQFafRsLixjYQBPr11j30cr75Jv/TfI+PGrf MQihc8lZBipmpDj7P+WE2L68uiEck7ViKUCVUxYKpIFFLVvJrYZKAOXntyAnfGsv3l70 vbGmjJlFbiIgyn2wiIhGaF7a/f7ZAu9ITW/z73tPZ9Y9faueB6T5kSgp+jKA75zSWh8+ 1GJHYitnWWYe5wXuVS17Wk+PjQzShpCXStpnKhcIF+4wDDYpGugsAsTVL1pFUhIyjSkD WMQA/GfwuTCgZQqlb4nUCr374FmhgkUfPdvhE88XUW1QybGHoZIsoYA4PECGCNSpUb56 SYpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=cpH51Jlw2DMsRHspgboLmcc1an/7c473Q+RCXV6FNLE=; b=T0FBFvDEBYlUegx4P6B9VXPrSPZRxyTQUG9jaqGWxdt/YUTtm1FKi5LQnWvhT+keA5 46DORbr1P5VnU3slJYfSJZUnMNKxZdHf0+YDNmoG53xgP6FxvJ3Eo9exmIIRb20CckTY xkAE0+fAGpnKH9eAMUD6fRyeZcLC2xObuShUGU4auYhAySvivccHRsz5ehFhGm5zHwuD USznWZxtzarSTNaY5lfZ/wrObHcZVQhdSCMusumYAWPorNy7dfNrlISXEhaKMStC4QOK NknULybWFkDSjrcHlirHPEKhXHgAlqfxNi1A510U961BijEABtSPN135Y7WGCadCdXQW PkSQ== X-Gm-Message-State: ACgBeo3C6lZedtSkdecXQpDpJzu0MjoUcfd40WMVWzf6NTR5bOIAblLf xmjYgXu0RZNXUtlCK6YyBDrkLPLP9f4= X-Google-Smtp-Source: AA6agR5Mtf+SE3qtdqrzEKdGjN9+paZncQ4X/vOS1rU5zXGNqAHYLd6vgjZIeBwNeBTyFnXY3yTtcA== X-Received: by 2002:a05:6512:31c8:b0:492:ced3:ae7c with SMTP id j8-20020a05651231c800b00492ced3ae7cmr2248881lfe.6.1661008782760; Sat, 20 Aug 2022 08:19:42 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id k18-20020a2eb752000000b0025e4c49969fsm1093068ljo.98.2022.08.20.08.19.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Aug 2022 08:19:42 -0700 (PDT) Date: Sat, 20 Aug 2022 18:19:41 +0300 From: Dmitry Kozlyuk To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Stephen Hemminger" , Subject: Re: [RFC] Dynamic log/trace control via telemetry Message-ID: <20220820181941.24882e85@sovereign> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8727A@smartserver.smartshare.dk> References: <20220816021738.5498f802@sovereign> <20220816190837.40c557bb@hermes.local> <20220817181503.323b6230@sovereign> <98CBD80474FA8B44BF855DF32C47DC35D8727A@smartserver.smartshare.dk> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 2022-08-17 17:34 (UTC+0200), Morten Br=C3=B8rup: > > From: Dmitry Kozlyuk [mailto:dmitry.kozliuk@gmail.com] > > Sent: Wednesday, 17 August 2022 17.15 > >=20 > > 2022-08-16 19:08 (UTC-0700), Stephen Hemminger: =20 > > > Not sure if turning telemetry into a do all control api makes sense. = =20 > >=20 > > I'm sure it doesn't, for "do all". > > Controlling diagnostic collection and output, however, > > is directly related to the telemetry purpose. > > =20 > > > This seems like a different API. =20 >=20 > I agree with Stephen regarding not making the telemetry library a "do all= " control API. A separate API would be preferable. >=20 > And then, a wrapper through the telemetry interface can be provided to th= at API. Best of both worlds. :-) One of the reasons why I considered and suggested using the telemetry socket was that a new channel, protocol, and API would be an overkill for the task. It reminds me of an older "IF proxy library" proposal [1]. In the RFC discussion it was suggested that it could be a generic mechanism to deliver external events to DPDK, although, unlike events, commands need responses. I also found Thomas' message [2] that suggested log/trace control (never knew it was proposed already) but discouraged adding more interfaces. The final version of "IF proxy library" was nevertheless focused on netdev specifics and AFAICT never accepted because of questions from that side. So this RFC should be severely re-framed: 1) a generic event/command delive= ry mechanism is needed in principle, and 2) log/trace control can be the first usage of it, which may be easier to pull through than a complex interaction with OS networking stack. [1]: https://inbox.dpdk.org/dev/20200114142517.29522-1-aostruszka@marvell.c= om/ [2]: https://inbox.dpdk.org/dev/1734533.zqhfolzEdB@thomas/ >=20 > > > Also, the default would have to be disabled for application safety =20 > > reasons. > >=20 > > This feature would be for collecting additional info > > in case the collection was not planned and a restart is not desired. > > If it is disabled by default, it is likely to be off when it's needed. = =20 >=20 > All tracing, logging etc. MUST be disabled by default. You are suggesting= the opposite, which will definitely impact performance. >=20 > And performance will become a valid argument for not adding more trace/lo= gging to libraries, if all of it is enabled by default. >=20 > And my usual rant: I hope all of this can be disabled at build time - for= maximum performance. The feature is a dynamic equivalent of existing --log-level/--trace options. It doesn't affect performance until used to configure logs/traces that do. Other arguments to have it off by default are valid; just to clarify. >=20 > >=20 > > Let's consider how exactly can safety be compromised. > >=20 > > 1. Securing telemetry socket access is out of scope for DPDK, > > that is, any successful access is considered trusted. > >=20 > > 2. Even read-only telemetry still comes at cost, for example, > > memory telemetry takes a global lock that blocks all allocations, > > so affecting the app performance is already possible. > >=20 > > 3. Important logs and traces enabled at startup may be disabled > > dynamically. > > If it's an issue, the API can refuse to disable them. > >=20 > > 4. Bogus logs may flood the output and slow down the app. > > Bogus traces can exhaust disk space. > > Logs should be monitored automatically, so flooding is just an > > annoyance. > > Disk space can have a quota. > > Since the user is trusted (item 1), even if they do it by mistake, > > they can quickly correct themselves using the same API. > > =20 >=20 > Here's a thought: >=20 > Add an API to set an "unlock key", so applications who don't want to allo= w these features for unauthorized users can prevent them from enabling it. = Authorized users can use an API to unlock these features by providing the k= ey. Let's keep delegating AAA to an external proxy if needed. Unlock key would not remove Stephen's concerns, because it would still be another interface to analyze and to protect. Worse, it's a home-grown security mechanism to consider.