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 6F07141DEE for ; Mon, 6 Mar 2023 02:01:30 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF09A40ED6; Mon, 6 Mar 2023 02:01:29 +0100 (CET) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by mails.dpdk.org (Postfix) with ESMTP id BAC9140E03 for ; Mon, 6 Mar 2023 02:01:27 +0100 (CET) Received: by mail-yb1-f174.google.com with SMTP id t4so6594183ybg.11 for ; Sun, 05 Mar 2023 17:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678064487; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=gJWGtdG7JByZm9D32NAzK07XdsuHh3do1Iu5+NPfnz0=; b=kdQE3SxC9IW5GFUDMOgSDBrIEsOa1jOWzENaC+GBQqyNYDM5B+5ko/H23LBIzcC9wZ p05Ntfodsy+tRUOmPtrpE2+naz4WGf6JnZ8n/82fQFo7EMAf5IQyxP6KqBhJZgad5zaX LGBisTpjlfy4eEp+Nh2LTr8t200PRgDz1ioLR/qJkUTAUfyqnhUosMU4wC9Fh7VC1Pky c9H/Dr3ApMEFqNiqezO+qaJShb6XeZ0TSf/b0zvbcPBkXA2vOwe8SaednpWuSAnFTPNg D3/OVoIT/X60xuB2xoV175Fj9HlhQiGikUEzJTZxEWyQA0Ouz47/O9F4swiuCglB98ak 5gDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678064487; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gJWGtdG7JByZm9D32NAzK07XdsuHh3do1Iu5+NPfnz0=; b=VqkyDfJ18i4hZJqFQG2S5GOVmi5PTPx5TOKnXSBU5MQvOiw47sK73yF5mdWic0V1mI FSRTC2jt3pBVDJH1fvzHOqKmLEVHog1H/UmxzjT62C6DTqqSe8AAz1s3GUXoHcRDz8B7 nTf57YZWecaO3VK5U0loszYKzXkYSSUB0tDM5HJewkwd3tctKq0iSAIRKIg5w/GwipB3 6CRsz18aanVEv+1BmNz/MWzJxeM7Qx12D3/Wf5SyHOl3CAEthQqZYHLMVrmE7AUTGlLO JvIdXCdc9D8Xyse+LVHVtTKDGhvZfo2iTEnS7K8b08W74giikOgRdYKCPNS8KUt2tMXL QHOw== X-Gm-Message-State: AO0yUKUyyNcK/udIIHLYvlRHjB+Lh99TOE5YS/mgFsrmVtsX5n/7t/WO 12zxREJ+BWN8r2XwV91aKTr/xqjnlhiRq+dNFUIZiSaS0ntb7Q== X-Google-Smtp-Source: AK7set+8kg7WHuWvm6FsZ9vbgXnSk0nqYYlK3lOjTlsyjDHYbK+WXRAN7ki7/HHgoUVFTNRtQ8BqhR3UqZqbhMF7KX0= X-Received: by 2002:a5b:108:0:b0:8bb:dfe8:a33b with SMTP id 8-20020a5b0108000000b008bbdfe8a33bmr5383084ybx.9.1678064486821; Sun, 05 Mar 2023 17:01:26 -0800 (PST) MIME-Version: 1.0 From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Sun, 5 Mar 2023 20:01:15 -0500 Message-ID: Subject: Using rdtsc to timestamp RTT of packets To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000a5b3d605f630d516" 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 --000000000000a5b3d605f630d516 Content-Type: text/plain; charset="UTF-8" I convinced myself that a viable way to measure timestamps between a request packet and its response packet can be the difference between two Intel rdtsc calls The restrictions to valid use include: - RTT (time difference) must be calculated on the same CORE - fencing instructions (lfence) could be required The time difference is OK provided, - it delivers at least microsecond resolution (rdtsc does) - the difference is always positive (end-start) or zero - the details of whether the clock runs or does not run at the processor speed is not material so long as there's sufficient resolution - DPDK gives me the frequency rte_rdtsc_cycles(); this way I can convert from a rdtsc difference to elapsed time - The OS doesn't reset the counter or pause it for interrupts or on halts I think rdtsc does all this. But then I read [1]: - The TSC is not always invariant - And of course context switches (if a thread is not pinned to a core) will invalidate any time difference - The TSC is not incremented when the processor enters a deep sleep. I don't care about this because I'll turn off the power saving modes anyway So I am not so sure. Now, of course, Mellanox can report time stamps. Is it actually possible to get HW NIC timestamps reported for every packet sent and received without overburdening the NIC? Based on what I can see for my case (Connect 4 LX) resolution is nanoseconds. So I am tempted to not fool around with rdtsc and just use NIC timestamps. What is praxis in DPDK programming when one needs RTTs? [1] https://stackoverflow.com/questions/42189976/calculate-system-time-using-rdtsc --000000000000a5b3d605f630d516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I convinced myself that a viable way to measure timestamps= between a request packet and its response packet can be the difference bet= ween two Intel rdtsc calls

The restrictions to valid use include:
  • RTT (time difference) must be calculated on the same CORE
  • = fencing instructions (lfence) could be required
The time diff= erence is OK provided,
  • it delivers at least microsecond r= esolution (rdtsc does)
  • the difference is always positive=C2=A0(end-= start) or zero
  • the details of whether the clock runs or does not ru= n at the processor speed is not material so long as there's sufficient = resolution
  • DPDK gives me the frequency rte_rdtsc_cycles(); this way= I can convert from a rdtsc difference to elapsed time
  • The OS doesn= 't reset the counter or pause it for interrupts or on halts
I think rdtsc does all this. But then I read [1]:
  • The TS= C is not always invariant
  • And of course context switches (if a thre= ad is not pinned to a core) will invalidate any time difference
  • The= TSC is not incremented when the processor enters a deep sleep. I don't= care about this because I'll turn off the power saving modes anyway
So I am not so sure.=C2=A0

Now, of course, Mellan= ox can report time stamps. Is it actually possible to get HW NIC timestamps= reported for every packet sent and received without overburdening the NIC?= Based on what I can see for my case (Connect 4 LX) resolution is nanosecon= ds. So I am tempted to not fool around with rdtsc and just use NIC timestam= ps.

What is praxis in DPDK programming when one needs RTTs?
=
--000000000000a5b3d605f630d516--