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 0C596A0093 for ; Wed, 11 May 2022 18:08:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 000184111B; Wed, 11 May 2022 18:08:19 +0200 (CEST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by mails.dpdk.org (Postfix) with ESMTP id 2220D406B4 for ; Wed, 11 May 2022 18:08:18 +0200 (CEST) Received: by mail-pf1-f172.google.com with SMTP id d25so2369468pfo.10 for ; Wed, 11 May 2022 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EEYZdJmNVfXUl7NUrLhlinu7JZuOlccoHEs2Pe64rPI=; b=GpTeYgKXZWEW2HCL/mIF462OXB3LKzGkLOnBJE3HI5bjYmMhSwIlAdHJBpKy0liKFV Wp00KIJ911g5rYxXBtNqmFTxj/pjkUEqRIwAaeQ63ov7Am8CmlLdLRfh/jkp6JsaWi89 9/cU1aT4+Ik3t1hmlmED7SgK/3tC6M0WexW48/m1+R2xnlorvbaBpmO0ov/OItiQIhL2 roDFdX9mzeQtOYtDs65uGRf/HUjp4rl5ZR7wKSqvaIe3f447PN5pIipJt9Nadfk8FoRd X3GjAtSMAwulkO5hLffF8QZROtc025lcgF8i5KwyNCSJ+nzF3lzg6bseH2NLNRK+/DQ9 broA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EEYZdJmNVfXUl7NUrLhlinu7JZuOlccoHEs2Pe64rPI=; b=moWCfVrPgpo7m4pavqf6/UMU/ugetb8N0N9OhQsyGDvLO8pgH5XsgSDO+2hjhlJhy2 +p1texDzyy6KQssiPnHCuObRPZxi7KvlnO5w9mZZ1Hri1+184gcFLUgp8tNKzqy8XojT Cdzx79KboLKeiynTdDjNzPtVcEBepQf0MX4PMlf97Z3jDpSnj2LHJfHGMQk2eApVDM8C 7PoRupyFUukPboalcDuacsSoT8oViwDJ8Mra9m28txLVDCK021QBmyBZuifinAQLAUI3 3VxyofB83YB2fgIEkVJedoaPeou1owQx0+gq+eZvCdmUkZBKpcZ4+uQnZOgkvN6eYHH5 Fztw== X-Gm-Message-State: AOAM531Gkq3bMfN1/gniNnB2cmMt/0oCyfZjnKLWrZ4/EwzRdaE0ozst GjdfP3hDVKWGN/DZxWzs1hcbBQ== X-Google-Smtp-Source: ABdhPJxSw3Ksi38zJ4t7Sn8Njn+n4VYlaMMuCRS5N2AdWF8R03Z6MJQecD6ueid4aJ6P419TUmBxkw== X-Received: by 2002:a05:6a00:1494:b0:50e:23d:831c with SMTP id v20-20020a056a00149400b0050e023d831cmr26127879pfu.31.1652285297124; Wed, 11 May 2022 09:08:17 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id f7-20020a170902ab8700b0015e8d4eb233sm2060093plr.125.2022.05.11.09.08.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 May 2022 09:08:16 -0700 (PDT) Date: Wed, 11 May 2022 09:08:13 -0700 From: Stephen Hemminger To: Quentin Armitage Cc: Reshma Pattan , Ray Kinsella , dev@dpdk.org, stable@dpdk.org Subject: Re: [PATCH] libpcapng: fix timestamp wrapping in output files Message-ID: <20220511090813.3ef8d923@hermes.local> In-Reply-To: <20220507161237.207805-1-quentin@armitage.org.uk> References: <20220507161237.207805-1-quentin@armitage.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Sat, 7 May 2022 17:12:36 +0100 Quentin Armitage wrote: > In pcap_tsc_to_ns(), delta * NSEC_PER_SEC will overflow approx 8 > seconds after pcap_init is called when using a TSC with a frequency > of 2.5GHz. > > To avoid the overflow, reread the time and TSC once > delta * NSEC_PER_SEC > (1 << 63). In order to ensure that there > is no overflow if there is a several second gap between calls to > pcapng_tsc_to_ns() the actual check to reread the clock is: > delta > ((1ULL << 63) / NSEC_PER_SEC) > > Fixes: 8d23ce8f5ee ("pcapng: add new library for writing pcapng files") > Cc: stable@dpdk.org > > Signed-off-by: Quentin Armitage > --- > lib/pcapng/rte_pcapng.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c > index 90b2f5bc69..7770be725f 100644 > --- a/lib/pcapng/rte_pcapng.c > +++ b/lib/pcapng/rte_pcapng.c > @@ -34,7 +34,7 @@ struct rte_pcapng { > }; > > /* For converting TSC cycles to PCAPNG ns format */ > -struct pcapng_time { > +static struct pcapng_time { > uint64_t ns; > uint64_t cycles; > } pcapng_time; > @@ -53,7 +53,21 @@ static uint64_t pcapng_tsc_to_ns(uint64_t cycles) > { > uint64_t delta; > > + /* With a TSC frequency of 2.5GHz, delta * NSEC_PER_SEC will > + * wrap in under 8 seconds. Once half that time has elapsed > + * reread the system clock and TSC to ensure wrapping does not > + * occur. > + */ > delta = cycles - pcapng_time.cycles; > + if (delta > ((1ULL << 63) / NSEC_PER_SEC)) { > + pcapng_init(); > + if (cycles > pcapng_time.cycles) > + delta = cycles - pcapng_time.cycles; > + else { > + delta = pcapng_time.cycles - cycles; > + return pcapng_time.ns - (delta * NSEC_PER_SEC) / rte_get_tsc_hz(); > + } > + } > return pcapng_time.ns + (delta * NSEC_PER_SEC) / rte_get_tsc_hz(); > } > Can't this be fixed by scaling better? Calling pcapng_init in fast path would cause a system call, thats bad.