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 61E21425FC for ; Wed, 20 Sep 2023 20:54:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25D18402BA; Wed, 20 Sep 2023 20:54:10 +0200 (CEST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by mails.dpdk.org (Postfix) with ESMTP id C08FB40277 for ; Wed, 20 Sep 2023 20:54:08 +0200 (CEST) Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2b9c907bc68so1922541fa.2 for ; Wed, 20 Sep 2023 11:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695236048; x=1695840848; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zmp1bUdbOprY7dkiMGrP7gSXM8h/qaThqjLPNwD4EoQ=; b=DYOPQWTZoPNM8asloLWboR3ALyqDqp+4y8dGwWv3XaCFjd1BEr6Db2kkxKZotXrGtP 1P5bVZyiTlgX5SBqtyMFxDPdTCWEDicux4V9h1yjABfRVbQDcFvsIF7deEJzTgREwKx7 ZrwThCVg1WHm2xh8j6UIxiEyWtFgo3it5kPYgfNYYRB4n4yqLCETs1T79RoGOkm8zof9 hMNw9oltZylktqL/RY8CKW0uanXbBPAskt6Ovg0miuABUR18gn9DgenvUXEKvmGIvg/F L8NPliZTPxEx/QQzQPsBxbBDATNRNB3LfMobfHAzwpQjYNHg/JeGnXnDwGx8mXDwu3gr r0fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695236048; x=1695840848; h=content-transfer-encoding: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=zmp1bUdbOprY7dkiMGrP7gSXM8h/qaThqjLPNwD4EoQ=; b=MgFFukCzYI8LVy5XlYpStJ2pov9lSUVaTN9ykcCF35Mn7LuWsIuRXyY3dvB2KC+QkD Fuxb4nLcz58xsAaOmMvZsHGr/K4eQys2jsMjNtZEZ4yu2U9IjUF2wzhybOm/zEL4oSFk c6lPnZaaTR1iSDfbCEmuPq6FmZ/1dvhHykQuU4Pi0B31+Tgn0rGSjP4AIKvzKqL0Kuht eA47apBk4ROcHYjEGWckLNGuVdsK/ppp2AQZUL7VKF2dlm6LtulOAWjztEm5NqXhaEQJ Y7eZecJrynqFJCztorpFlI9KNLa+W0ygMWge3c4W4HG25ehYY+BnPSONeP2lGAUVndzZ mK0A== X-Gm-Message-State: AOJu0Yx4x8xCDqC253FiakV4QYABbOZpmK+8J+bp75YjfetgcCCVv8tX 8YoPd+eb46QcnMYEhh8hPd5/NUc2nXW0JvcuuYk= X-Google-Smtp-Source: AGHT+IHvT2A2IWqaoauRg29zUJ0x5fXYC92SRr/KF3YXo0xJcD4IPLPDgDP3XZoR+9/Z3Qov0z4UyqzZ8GabuFqpzvM= X-Received: by 2002:a2e:8017:0:b0:2bf:7dac:a41 with SMTP id j23-20020a2e8017000000b002bf7dac0a41mr2550145ljg.13.1695236047685; Wed, 20 Sep 2023 11:54:07 -0700 (PDT) MIME-Version: 1.0 References: <20230919110009.29e90615@hermes.local> In-Reply-To: From: Isaac Boukris Date: Wed, 20 Sep 2023 21:53:54 +0300 Message-ID: Subject: Re: dumpcap: timestamp is years ahead when in pcapng format To: Stephen Hemminger Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org I figured the first packet bug, fixed with: - if (!pcapng_time.tsc_hz) + if (!pcapng_time.tsc_hz) { pcapng_init(); + return pcapng_time.ns; + } However I noticed a caveat with my proposed fix as it seem we only get a time resolution of one sec: 2023-09-20 09:40:20.727638 IP Rocky8 > A: ICMP echo request, id 11, seq 81, length 64 2023-09-20 09:40:20.727638 IP A > Rocky8: ICMP echo reply, id 11, seq 81, length 64 2023-09-20 09:40:21.727638 IP ... On Wed, Sep 20, 2023 at 8:59=E2=80=AFPM Isaac Boukris = wrote: > > On Tue, Sep 19, 2023 at 9:00=E2=80=AFPM Stephen Hemminger > wrote: > > > > On Tue, 19 Sep 2023 19:35:55 +0300 > > Isaac Boukris wrote: > > > > > Looking with git log, i found the original line was: > > > return pcapng_time.ns + (delta * NSEC_PER_SEC) / rte_get_tsc_hz(); > > > > > > Testing that does show a wrapping issue, e.g. (it stays around 08:05)= . > > > > > > 2023-09-19 08:05:24.372037 IP _gateway.domain > Rocky8.38358: 31975 > > > NXDomain 0/0/0 (46) 10 > > > 2023-09-19 08:05:21.577497 ARP, Request who-has _gateway tell Rocky8, > > > length 46 > > > 2023-09-19 08:05:21.577599 ARP, Reply _gateway is-at 00:50:56:f8:92:7= 6 > > > (oui Unknown), length 46 13 > > > 2023-09-19 08:05:22.833897 IP 192.168.202.1.50886 > > > > 239.255.255.250.ssdp: UDP, length 174 > > > > > > However with my change it looks fine and always increments. I dropped > > > all the parenthesis: > > > return pcapng_time.ns + delta / pcapng_time.tsc_hz * NSEC_PER_SEC; > > > > The issue is that timestamping is in the fast path and that 64 bit divi= de is slow. > > Looking at other alternatives. > > Then perhaps we can keep the division optimization and just get rid of > the overflow check, relying on the change to multiply by NSEC_PER_SEC > after the division. > > With the below change only the first packet is from 2257 while all > subsequent packets are fine. But if I keep the overflow check and only > change to multiply after the division, then all packets are shown from > 2257. > > [admin@Rocky8 dpdk]$ git diff lib/pcapng/rte_pcapng.c > diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c > index 80d08e1..fa545cd 100644 > --- a/lib/pcapng/rte_pcapng.c > +++ b/lib/pcapng/rte_pcapng.c > @@ -79,7 +79,7 @@ static uint64_t pcapng_tsc_to_ns(uint64_t cycles) > * Currently all TSCs operate below 5GHz. > */ > delta =3D cycles - pcapng_time.cycles; > - if (unlikely(delta >=3D pcapng_time.tsc_hz)) { > + if (0 && unlikely(delta >=3D pcapng_time.tsc_hz)) { > if (likely(delta < pcapng_time.tsc_hz * 2)) { > delta -=3D pcapng_time.tsc_hz; > pcapng_time.cycles +=3D pcapng_time.tsc_hz; > @@ -92,8 +92,9 @@ static uint64_t pcapng_tsc_to_ns(uint64_t cycles) > } > } > > - return pcapng_time.ns + rte_reciprocal_divide_u64(delta * NSEC_PE= R_SEC, > - > &pcapng_time.tsc_hz_inverse); > + return pcapng_time.ns + rte_reciprocal_divide_u64(delta, > + > &pcapng_time.tsc_hz_inverse) * NSEC_PER_SEC; > }