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 2A9D1426AE for ; Tue, 3 Oct 2023 12:19:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 911B5402A2; Tue, 3 Oct 2023 12:19:14 +0200 (CEST) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by mails.dpdk.org (Postfix) with ESMTP id 7A76C4026B for ; Tue, 3 Oct 2023 12:19:12 +0200 (CEST) Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-d8a000f6a51so821934276.3 for ; Tue, 03 Oct 2023 03:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696328352; x=1696933152; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jFwDVbGtgY/TamFDZZyTdx4pW3JVWIF62Ps7XaQS8gk=; b=ipLf9UYqdOxkpJTU56s7Lzfe0vSU2zKS4CQfIODhkLkKWOx46Wjg8pCxt62chsghxZ 9UlK9v2fSy0c8kj7gm4o+LbnrIeEG/sO16bv4X+i2m1csFl5EjPQbt6Rt+unNilOKgAs 6Y3zfsk32OVnmINvJwH0lisLN9tqviXfP5TbXbvxlMRqkQVDEF97kJO9edffwD23c8Jr 2UIWmxUstMkV9yhA1baOJU0NN/fEin/EptJyAchrsuGOeTsR+jAvr1hZivi/qk0Q5Wak wMx+Yh5j20i2BU3O0UQ6xJzGDsqsy6BLI6ZQiJgsuuj+G91kANM20/5PS13oiZFdu7uw Vxcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696328352; x=1696933152; h=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=jFwDVbGtgY/TamFDZZyTdx4pW3JVWIF62Ps7XaQS8gk=; b=HHXIJ333vq4Legc6cW/fzna6DMvj1lopKhko+mh1UqK/NbnSTzemokOuvnc833J8cG 3cGSnusFkrh0jmf4Amyy2ikScUnmxFwiJphbd4V3wK2Ly1CWEwGsXX3oh5KbNn7zGxgs 3C1gAGELGuogwo/KxmuwYa22K4aZ5u+2nrtc8stSplcMmtpwri7wFbwlZAdhbQkEIdUy 3UforUZlNhGdvtVyoLf4LxNNzpPYrgqhzuloU2L5ntig66qDY4HBedE+1wxlzKHy3Kws QgOaGKVHPd6sGhIwe/RhE7iJID/IKb/lspzzpuu3gqDnxStucFO9b0MSxefIYjxM0v3p JBVg== X-Gm-Message-State: AOJu0YzOHZ+vBlLeXTYRjNpJBs3medVzr+iyG0DQgqyBSL21euMDagJB B53zm+UoGjrnsm8VfjR6na90FseRkcNrbMDAB3xj1hBfzKM= X-Google-Smtp-Source: AGHT+IHDOI4ITXy2xoytACC0E/DLWdwdt7sjYjH9DUZ9Z2xL+yqQRVNvxCIYwdvd233RiGey5xlbX9YjsEMmPyf+L8o= X-Received: by 2002:a25:9f0a:0:b0:d90:e590:eb0d with SMTP id n10-20020a259f0a000000b00d90e590eb0dmr4385929ybq.26.1696328351675; Tue, 03 Oct 2023 03:19:11 -0700 (PDT) MIME-Version: 1.0 References: <20230905162929.3dbc9e12@hermes.local> In-Reply-To: <20230905162929.3dbc9e12@hermes.local> From: Hari Haran Date: Tue, 3 Oct 2023 15:49:00 +0530 Message-ID: Subject: Re: rte_rdtsc() - what is the performance impact of using rte_rdtsc() time To: stephen@networkplumber.org Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000d2f97e0606cd38a6" 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 --000000000000d2f97e0606cd38a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 6, 2023 at 4:59=E2=80=AFAM Stephen Hemminger wrote: > On Tue, 29 Aug 2023 20:25:54 +0530 > Hari Haran wrote: > > > Hi All, > > > > Subject: rte_rdtsc() - what is the performance impact of using > rte_rdtsc() > > time under lcore thread while(1) > > > > Requirement: > > > > 1. Store the packet received timestamp - based on it packets will be > > removed from buffer if it exceeds the threshold timer of buffer > > 2. Two threads are available, One is lcore(dedicated core) and anoth= er > > is pthread(not a dedicated core. In pthread, have to get the > timestamp of > > last received packet timestamp > > > > > > Query: > > > > 1. For every packet reception in lcore thread under while(1), will g= et > > the packet received timestamp using rte_rdtsc() function. Whether > usage of > > rte_rdtsc() function adds more delay in packet processing? > > 2. Is there any way to convert rte_rdtsc() timestamp value to curren= t > > system time in pthread()? In pthread, the last packet received time > needed > > in the form of system time. > > > > > > Thanks in advance. > > > > Regards, > > Hariharan > > The problem is that rte_rdtsc() stops speculative execution so doing > lots of TSC instructions can hurt performance. > > To correlate TSC timestamp to system time, you need to compute the offset= s > once at startup. Alternatively, don't use rte_rdtsc() and instead use > clock_gettime() with the monotonic timer and the C library does the > calculation > for you. > As part of query 1 and based on your response, I am asking below query But usage of clock_gettime() (kernel function) in lcore is advisable one? My understanding is, shall avoid usage of kernel function in lcore. Correct me if I am wrong? TIA. Regards, Hariharan --000000000000d2f97e0606cd38a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 6, 2023 at 4:59=E2=80=AFA= M Stephen Hemminger <steph= en@networkplumber.org> wrote:
On Tue, 29 Aug 2023 20:25:54 +0530
Hari Haran <info2hariharan@gmail.com> wrote:

> Hi All,
>
> Subject: rte_rdtsc() - what is the performance impact of using rte_rdt= sc()
> time under lcore thread while(1)
>
> Requirement:
>
>=C2=A0 =C2=A0 1. Store the packet received timestamp - based on it pack= ets will be
>=C2=A0 =C2=A0 removed from buffer if it exceeds the threshold timer of = buffer
>=C2=A0 =C2=A0 2. Two threads are available, One is lcore(dedicated core= ) and another
>=C2=A0 =C2=A0 is pthread(not a dedicated core. In pthread, have to get = the timestamp of
>=C2=A0 =C2=A0 last received packet timestamp
>
>
> Query:
>
>=C2=A0 =C2=A0 1. For every packet reception in lcore thread under while= (1), will get
>=C2=A0 =C2=A0 the packet received timestamp using=C2=A0 rte_rdtsc() fun= ction. Whether usage of
>=C2=A0 =C2=A0 rte_rdtsc() function adds more delay in packet processing= ?
>=C2=A0 =C2=A0 2. Is there any way to convert rte_rdtsc() timestamp valu= e to current
>=C2=A0 =C2=A0 system time in pthread()? In pthread, the last packet rec= eived time needed
>=C2=A0 =C2=A0 in the form of system time.
>
>
> Thanks in advance.
>
> Regards,
> Hariharan

The problem is that rte_rdtsc() stops speculative execution so doing
lots of TSC instructions can hurt performance.

To correlate TSC timestamp to system time, you need to compute the offsets<= br> once at startup. Alternatively, don't use rte_rdtsc() and instead use clock_gettime() with the monotonic timer and the C library does the calcula= tion
for you.


As part of quer= y 1 and based on your response, I am asking below query

But usage of clock_gettime() (kernel function) in lcore is=C2=A0advis= able one? My understanding is,=C2=A0
shall avoid usage of kernel = function in lcore. Correct me if I am wrong?=C2=A0

TIA.=C2=A0

Regards,
Hariharan=C2=A0
=C2=A0
--000000000000d2f97e0606cd38a6--