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 1B9B9A00C2 for ; Thu, 13 Oct 2022 21:11:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1359241155; Thu, 13 Oct 2022 21:11:16 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id DDA3041156 for ; Thu, 13 Oct 2022 21:11:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665688273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fJftnQMrw22gOmWYMxLrtv6a8E6HVgaWiofPg3X9e1s=; b=XALUIbW7mBws12aSQ1iihD9JbwqnqCf8BO173yiM6RpE1wNGJF5K5TpXNpVX6lNR/8TADc lVvY3ABbcy+lFxSzmY533gSiRHM9B+2CjfEbQbPX8aGou+mUcFyWRax/wzge03RerXayFV 8FLeoq44pLnjBSHQ9rcv7z/QIPWfNVo= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-605-VrQrUpDJMbm2yixmuN9--w-1; Thu, 13 Oct 2022 15:11:06 -0400 X-MC-Unique: VrQrUpDJMbm2yixmuN9--w-1 Received: by mail-pf1-f200.google.com with SMTP id n56-20020a056a000d7800b00562b27194d1so1629782pfv.19 for ; Thu, 13 Oct 2022 12:11:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=fJftnQMrw22gOmWYMxLrtv6a8E6HVgaWiofPg3X9e1s=; b=YHaaXaF9FTSUvosO5OmEGub+8sHumChsKnpT9csu7O80nDQiBgyl0+8DvZGw3cfQkO +f6CxVSFodcXkiaNo+c2XnbFUTgs96Z4zg85CkXa08khLsonJu8yqp8u0QyM6koiLGyw hR310EXweGt0VgBngy7piB8bIwshUk6lF7MTTi/jxc2YnnKi3iuDgW/cKe5PFhbtPwyp WvieZhgzUKpyN1Jk8E1GhJ+LxHLWGnUdLd1LM5T9CCdkC2vpsw14yVhe2Kmdu8ot+qE7 kQni+pX6Vo7fGsQN5xh3MYIjY4+ogJ76Ffv450WG2D2fbSPkwcYntINXv2gMBHygKJcq D4Hw== X-Gm-Message-State: ACrzQf2ox39PraEAD19/aSpR2uWj/6/7Y/9WevfHPBrWu57slziH7KWs 3Rsvf4u5ckqrhIGWsgv5rIDFmWhaIjkqTQXifjrkHeVjx1d3OuCHgT/y161Fo4G+4SbmsCQvWuq C/4fE6gvCDy4MfAxu1xMdLjc= X-Received: by 2002:a17:903:2307:b0:181:e618:b4c5 with SMTP id d7-20020a170903230700b00181e618b4c5mr1396079plh.172.1665688263600; Thu, 13 Oct 2022 12:11:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4CU3LIQ3YkfkWGf1KGC1a1GcYd6pPFhy0TfmT88WQItaXM8bYe9P2YBRuSrCxdveJ3JrZ1hbrfYXOC+l1mTDI= X-Received: by 2002:a17:903:2307:b0:181:e618:b4c5 with SMTP id d7-20020a170903230700b00181e618b4c5mr1396062plh.172.1665688263334; Thu, 13 Oct 2022 12:11:03 -0700 (PDT) MIME-Version: 1.0 References: <20220921120359.2201131-1-david.marchand@redhat.com> <20221012123112.2951802-1-david.marchand@redhat.com> <20221012123112.2951802-6-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Thu, 13 Oct 2022 21:10:51 +0200 Message-ID: Subject: Re: [EXT] [PATCH v3 5/9] trace: fix dynamically enabling trace points To: Harman Kalra , Jerin Jacob Kollanukkaran , Sunil Kumar Kori Cc: "dev@dpdk.org" , "stable@dpdk.org" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Thu, Oct 13, 2022 at 7:07 PM Harman Kalra wrote: > > > > With the whole traces fixes series applied first, then the new "trace: > > take live traces via telemetry" patch applied, I can't reproduce your issue. > > > > > > Yes, you replicated the same scenario what I tried. > Sorry, I realized that actually it's not an issue, traces generated after /trace/save are getting > appended but in the same file (timestamped on /trace/save) on rte_eal_cleanup(). > > I assumed that trace dir generated with a timestamp will include all the trace points emitted > before that timestamp. But in the above scenario same trace dir includes trace points emitted > after this timestamp. I think this is bit confusing. Shall we add a logic where if already_done is > set, rename the original trace dir to latest timestamp? Afaiu, the behavior before this series was the same. An application calling rte_trace_save() would always save to a single directory. One thing that changed though is that the directory is timestamped with the time of the first call to rte_trace_save. Before the seriesn the timestamp was based on the time when the trace subsystem was initialised. We can go with what you describe (which makes sense to me). But I'd like to get a ack from traces maintainers before looking into it. -- David Marchand