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 8BC18A00C2; Thu, 13 Oct 2022 21:11:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 364A94014F; Thu, 13 Oct 2022 21:11:08 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 6AA5E400D4 for ; Thu, 13 Oct 2022 21:11:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665688266; 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=Q0wUVBk2n3u/gxzcNwzeJZqKOr2dK3N9hiJmuDDZZJRv2EE06aP+Jf2dngsjwLPzViCENL hde5YWuNM/3j0cvppcTfQY9ruicppzInP2V+aTiQoCSXSEfCkBJoNws9NSAjgZaIW+KbPZ 2X5bdWDY+rFEsbMy0RFuhIg7FCjaQoE= Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-612-7ea6Bf_-MBOW2OOIi-kEBw-1; Thu, 13 Oct 2022 15:11:05 -0400 X-MC-Unique: 7ea6Bf_-MBOW2OOIi-kEBw-1 Received: by mail-pg1-f197.google.com with SMTP id b11-20020a630c0b000000b0044c0bb18323so1446860pgl.17 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=a03wyJ/QutupQ3wz+6Cx1I1mZgSPp8DQsjUqsqrLIv45sGhxQ55SqmyU18cjA9CnJ5 TUyQc/IVmvG/ojrSB0Bt3dXuY/vXVGq4yCJ4SDlrsg9eMRDGzsdZ7zzYxNebGPE+T2+2 NIeLkmG8s1uTjRqC/EnNqVITNenpjRFsYdamBo6f91n4pH0TQjBz0fct90sw5u3zwKlR htQrc1G6RJog8s7m5TxIoOAY8L8U52MM8boPazNFPuCD0FnCMsZR3qgQt8NvUZA12EiV +FhaaYjBVJViSDqfEibFTlt9qy/xyeQ9GNFA4CIveVKUj1VI7U8WcTFavcRCy+dMbiCQ J8nA== X-Gm-Message-State: ACrzQf1O8eUdIgyAHl1269c+Fis72XJoTrAuO5LpfajxGrfbigpKCXEx p0JCZ3NHAz98nRKQI5UWcLJyyvScNMQlM7OsezsSXreUX1mWGuHOrfmZQ2OFH8y62laybIvJ/G9 rwfjxCu2JfrS/ZB11tfE= X-Received: by 2002:a17:903:2307:b0:181:e618:b4c5 with SMTP id d7-20020a170903230700b00181e618b4c5mr1396081plh.172.1665688263601; 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: 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, 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