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 1CBA6425FD for ; Wed, 20 Sep 2023 20:00:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D99F840E4A; Wed, 20 Sep 2023 20:00:04 +0200 (CEST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by mails.dpdk.org (Postfix) with ESMTP id 662CA402C3 for ; Wed, 20 Sep 2023 20:00:03 +0200 (CEST) Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2bffd6c1460so796141fa.3 for ; Wed, 20 Sep 2023 11:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695232802; x=1695837602; 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=Yjl8wqqPj9LNBMbnQTVCn3bQtqLUREwgtfXXyxrSQMc=; b=DDYoSEFrSh63VKaWrAAKHGBol0vEgeED97Oc94kHyNtuIn/FjoYy3tzFvUgyDTj0KG pVaBXTpfV11tT4lcXW68P0R8NtNdAEwj/kRztsyTZefxmKvbsLZmdawwevIx2F1Sxwkj 2vwqQNhUyBQMy7VT1H6pxixJxvktNZyMKk4Zoc/QLfu09AWHTvpjpx4RjHF153pJreJA gETD93QUi2NYlyXbl48/2oexPWcrF8SOFfFXCb3X8YhxmdN4JhMtQ+NgufYPyFqpRQ7w aqW8UAzhDGAYFfEoHnJAsuAt8zntrqU6YqHZ2ciTw/QC/8ia3QSJQx+qq/948yOTZYHj deTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695232802; x=1695837602; 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=Yjl8wqqPj9LNBMbnQTVCn3bQtqLUREwgtfXXyxrSQMc=; b=smikDrlws2YGqCaI/LJan1J2xn73U/5iLsID5dJ1tgMda0PuU5xB3mpSrZfsGEdmwh qZw54fmH6MM88wPN/0ce315NLFAdcmHU5Z03YAOrtwGS8tvu0E31D50YEmPpYV3gB3g2 eWtt6YMDj1GT1HXIsxQNx1bNBDTLasOSQCC8d8V6SOov788qkGQVmReg7jveSMKad1HC 8NbNOs9y8BCGCb58A4EQBmmboxakdnOF00cHfHPcF7UidDzANiBr83T85IPGXkEf5NMD 7+wkdd8LdrS/u/cOkMrmK5JBKfwrMxeXJCFJrAVPOoNjWt9DoB1239VkJUZpcXeKI9a1 1c6A== X-Gm-Message-State: AOJu0YyRaD8VME1KtcQY3OjFC3qYauQyLrynVSOot8bPS6YzLOkDtAGH 1O8H6Tydn+dmvLDvh/imboQPdjz2Oit4hM5b61f1OAagN6U= X-Google-Smtp-Source: AGHT+IHNdsp86+bSMh93HX8SocLeXr/s5htA99TpklIMIRnSlwz85rN2A4Xvcj0B0c+pYK0e8Z1/R9r/giM1jT7ALGA= X-Received: by 2002:a05:651c:210:b0:2bf:789e:b5dd with SMTP id y16-20020a05651c021000b002bf789eb5ddmr2643313ljn.53.1695232802274; Wed, 20 Sep 2023 11:00:02 -0700 (PDT) MIME-Version: 1.0 References: <20230919110009.29e90615@hermes.local> In-Reply-To: <20230919110009.29e90615@hermes.local> From: Isaac Boukris Date: Wed, 20 Sep 2023 20:59:48 +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 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:76 > > (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 divide= 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_PER_= SEC, - &pcapng_time.tsc_hz_inverse); + return pcapng_time.ns + rte_reciprocal_divide_u64(delta, + &pcapng_time.tsc_hz_inverse) * NSEC_PER_SEC; }