From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 0C596A0093
for <public@inbox.dpdk.org>; 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 <stable@dpdk.org>; Wed, 11 May 2022 18:08:18 +0200 (CEST)
Received: by mail-pf1-f172.google.com with SMTP id d25so2369468pfo.10
for <stable@dpdk.org>; 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 <stephen@networkplumber.org>
To: Quentin Armitage <quentin@armitage.org.uk>
Cc: Reshma Pattan <reshma.pattan@intel.com>, Ray Kinsella <mdr@ashroe.eu>,
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 <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
On Sat, 7 May 2022 17:12:36 +0100
Quentin Armitage <quentin@armitage.org.uk> 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 <quentin@armitage.org.uk>
> ---
> 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.