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 E5247A0032; Wed, 17 Aug 2022 17:34:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E0F04068E; Wed, 17 Aug 2022 17:34:20 +0200 (CEST) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 1C27C40685 for ; Wed, 17 Aug 2022 17:34:19 +0200 (CEST) Received: by mail-pj1-f45.google.com with SMTP id s4-20020a17090a5d0400b001fabc6bb0baso858022pji.1 for ; Wed, 17 Aug 2022 08:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc; bh=FRzHAk7gfNeM37SfmpkB4L9U51mZYRUSDkeBwnJsTj4=; b=h/Kbacwv0xVuTJ/PdGTQxF2y3JG1H9PFdrBP/SVEh3RKaUY7eZHJGcBM/+A1GVIiUk GuGNEAvaqWM19t5OlXnrwB5B1znhb433qWSaWfV21A+8SagD/fHok9rGtmnEx6oNRo57 DeMrGU1eOwUW9xDjvvA4sHG6fIfDwyw6uKt9WY3+OTx9MGPjVO4DPQaNqsMY5Fs5aB7t MH3k11n5LTZdbwKx36fgRYUAZwxUrzTQbk91Z4JA1xViIIffJFbLFwkpfysdlVceB4eO Yp8UsHtRbGTjQblX2OHlhbckfDyw8xlbRdVbowJIoakuQOyGayzJ+nH0pZkcaoYztmqF EHxg== 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=FRzHAk7gfNeM37SfmpkB4L9U51mZYRUSDkeBwnJsTj4=; b=1NGihuuzQ8lJcEb2+jiEpFrnvphjKmGaKKh4QInOp0V0SuK24lPeZfs4rLzRC5WLZQ +3FCCJLAWhpwyQty2pu0mWHn80RZoNnG4sVCIkjMXM0OYBKXTrf33e1PlnAzQH6Yt6wB S8TLIp1N1hM9AlkLxJgiZt4ChkgVSBHoA4WH8wWMs4r2Fin31wvh4POQOzykM9D0MeJg 9z6W727Z8duIzczo/f/Dig0xocJ8ELV9TwRsI7W8YvDjXVHeY/hlQqYq/hkvm0VM5dO0 zYcHocVBSvoQpw+UwpyliAQDGL6L5ZrUvqIZSs3EC8pMCAZdPlMk0sA329L5QEvORgQj reRA== X-Gm-Message-State: ACgBeo3zvWpcjc12nXODGYFA2w3WM284AqSYRVHCWNQwczOD10nVuS48 +1UhskG50piecvJol2+0DrpbrA== X-Google-Smtp-Source: AA6agR5bSzE0rnI2Kg6IpnHpYuvj0h3GlnUYg5LIYBv2ujaJXsJHdb96a+DuQsq6SIXq4rU91GFsYQ== X-Received: by 2002:a17:902:7c90:b0:172:5f2a:9e3a with SMTP id y16-20020a1709027c9000b001725f2a9e3amr19584115pll.1.1660750458051; Wed, 17 Aug 2022 08:34:18 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id f14-20020a170902ce8e00b0016dd667d511sm35453plg.252.2022.08.17.08.34.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 08:34:17 -0700 (PDT) Date: Wed, 17 Aug 2022 08:34:15 -0700 From: Stephen Hemminger To: Dmitry Kozlyuk Cc: dev@dpdk.org Subject: Re: [RFC] Dynamic log/trace control via telemetry Message-ID: <20220817083415.4fce7758@hermes.local> In-Reply-To: <20220817181503.323b6230@sovereign> References: <20220816021738.5498f802@sovereign> <20220816190837.40c557bb@hermes.local> <20220817181503.323b6230@sovereign> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 17 Aug 2022 18:15:03 +0300 Dmitry Kozlyuk wrote: > 2022-08-16 19:08 (UTC-0700), Stephen Hemminger: > > Not sure if turning telemetry into a do all control api makes sense. > > I'm sure it doesn't, for "do all". > Controlling diagnostic collection and output, however, > is directly related to the telemetry purpose. > > > This seems like a different API. > > Also, the default would have to be disabled for application safety reasons. > > 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. > > Let's consider how exactly can safety be compromised. > > 1. Securing telemetry socket access is out of scope for DPDK, > that is, any successful access is considered trusted. > > 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. > > 3. Important logs and traces enabled at startup may be disabled dynamically. > If it's an issue, the API can refuse to disable them. > > 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. There can be security impact to telemetry. There always is some performance cost to telemetry. My interest is that we run a performance sensitive application and it gets lots of security review. If a new version of DPDK magically enabled something that had impact, you would cause extra effort and confusion. Developers often have the wrong point of view "my feature is great, everyone wants it" and also "why should I test with this disabled". New features should be opt-in not opt-out.