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 CD9C14596F; Thu, 12 Sep 2024 17:12:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89EEF4028F; Thu, 12 Sep 2024 17:12:27 +0200 (CEST) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by mails.dpdk.org (Postfix) with ESMTP id C1B3E42D87 for ; Thu, 12 Sep 2024 17:12:26 +0200 (CEST) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4585e25f42bso8806351cf.2 for ; Thu, 12 Sep 2024 08:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726153946; x=1726758746; 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=BSc+oW1DlkKZjw01KfDbsCsWxNfpMd1HUz466wCsVyI=; b=H/836lYL0b5wFQzxlucPfMZFbpuxYtdvda2n20UR38NVaKQNtDOA6GG1iViN8FQY7A PGY3f1Ns0T799ip4lhBw+eb1a5jZx2Y2fXt6t5oqDEpd263vVpMlLEcGVFEZsEADWd9d UG0Dpc08IXxrK4l6l4Tn9OndnICDat0bizqqRFIT9ehCVRfEB3Xrt5orr8Zl3or/WcLU +XZ5fMdWzsaCNZx3dyb/fFWz5/y4vUeiK5iBStLpYYrkcinffUvjxS2B7hJc8RwaORzO PQp2j4H7LcLdLsJZd6KKKbqmDa3HnbIbO3V4XbKMaRtYBOo/cNTxh4JHqdYbmtjxwNjh EqgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726153946; x=1726758746; 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=BSc+oW1DlkKZjw01KfDbsCsWxNfpMd1HUz466wCsVyI=; b=BfJo3BeiV71+BtP6EbxkOUCXA4WlWnYqQ+DpADQegW+nivXw3f51afoZUQTzhY5a60 Kd45Sn8405oYaIUpEmfFN1C4/H4fq3aa5Eycnngx359lmxD23zivdbaMsKxCGRZDptGN 44/WVuQzXv7TeLbx1OWYxBNoUsG3aHIWNIR4vXdUsGKN4ZXYsmBkUKIsKEcJ7V9oFvAG WJTMvHiRzkTyP+XXpj55hmcFNYROPQKNME/cSzw6Z06XGx0SbqC5rbZdCHUadlmk4Z9g DEZPYhC+8/FkMgoshjJ/cmZErB6vrMH6u9082DSXFamSHPxW9uDjmXqnB2lp+KiB7Rg5 nr3A== X-Forwarded-Encrypted: i=1; AJvYcCXqgTLsfMazK6K1sh7vfMXF6OszXVJlcZ+AwhG4CaeywfjqaTIfGN1EVybnJcFACylGGTk=@dpdk.org X-Gm-Message-State: AOJu0Yx6QM7pPIwvD4utEz6RMRrd4DRXWbPSVnZuwyM4sHUyXBsp8Qrv 4RUqtH5NDVl6gNOzoEseBlIwXu7gsk3GzTohJ9/aH2WrXXDyS5/pP3MZceR1nQf4458ZEvHDcS7 WOthjSX2tg9H4IthfCKdHR1l6P+U= X-Google-Smtp-Source: AGHT+IG33kHrANclNs8cDp3RkZmG8IcZdDtqbKFOvvZet9rQ4D3mzUd6h621XwKHMk4HX4ENFNLHwzRr483pC0Oo/3k= X-Received: by 2002:a05:622a:1a12:b0:458:5161:e0ca with SMTP id d75a77b69052e-458603d12e5mr46754601cf.41.1726153945813; Thu, 12 Sep 2024 08:12:25 -0700 (PDT) MIME-Version: 1.0 References: <20240911170430.701685-2-mattias.ronnblom@ericsson.com> <20240912084429.703405-1-mattias.ronnblom@ericsson.com> <20240912084429.703405-4-mattias.ronnblom@ericsson.com> <88a778d3-e157-41cd-9da7-2d06864a654d@lysator.liu.se> In-Reply-To: <88a778d3-e157-41cd-9da7-2d06864a654d@lysator.liu.se> From: Jerin Jacob Date: Thu, 12 Sep 2024 20:41:59 +0530 Message-ID: Subject: Re: [PATCH v3 3/7] eal: add lcore variable performance test To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= , Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Sep 12, 2024 at 6:50=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2024-09-12 15:09, Jerin Jacob wrote: > > On Thu, Sep 12, 2024 at 2:34=E2=80=AFPM Mattias R=C3=B6nnblom > > wrote: > >> > >> Add basic micro benchmark for lcore variables, in an attempt to assure > >> that the overhead isn't significantly greater than alternative > >> approaches, in scenarios where the benefits aren't expected to show up > >> (i.e., when plenty of cache is available compared to the working set > >> size of the per-lcore data). > >> > >> Signed-off-by: Mattias R=C3=B6nnblom > >> --- > >> app/test/meson.build | 1 + > >> app/test/test_lcore_var_perf.c | 160 +++++++++++++++++++++++++++++++= ++ > >> 2 files changed, 161 insertions(+) > >> create mode 100644 app/test/test_lcore_var_perf.c > > > > > >> +static double > >> +benchmark_access_method(void (*init_fun)(void), void (*update_fun)(vo= id)) > >> +{ > >> + uint64_t i; > >> + uint64_t start; > >> + uint64_t end; > >> + double latency; > >> + > >> + init_fun(); > >> + > >> + start =3D rte_get_timer_cycles(); > >> + > >> + for (i =3D 0; i < ITERATIONS; i++) > >> + update_fun(); > >> + > >> + end =3D rte_get_timer_cycles(); > > > > Use precise variant. rte_rdtsc_precise() or so to be accurate > > With 1e7 iterations, do you need rte_rdtsc_precise()? I suspect not. I was thinking in another way, with 1e7 iteration, the additional barrier on precise will be amortized, and we get more _deterministic_ behavior e.s.p in case if we print cycles and if we need to catch regressions. Furthermore, you may consider replacing rte_random() in fast path to running number or so if it is not deterministic in cycle computation.