From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id B903D43E24;
Sun, 7 Apr 2024 19:00:14 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 32D184029A;
Sun, 7 Apr 2024 19:00:14 +0200 (CEST)
Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com
[209.85.210.171])
by mails.dpdk.org (Postfix) with ESMTP id 08C064026F
for <dev@dpdk.org>; Sun, 7 Apr 2024 19:00:12 +0200 (CEST)
Received: by mail-pf1-f171.google.com with SMTP id
d2e1a72fcca58-6ed0938cd1dso1711221b3a.2
for <dev@dpdk.org>; Sun, 07 Apr 2024 10:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712509212;
x=1713114012; darn=dpdk.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=ImqPnegsfhSmEKPjHRSu4WjIe+y4DjLFN56t4phfAkg=;
b=GFWWR546HASaGKIg1rrdk8EBkTIDInNpctm4KWwiCfltkiTcjb07jhalH/uD01OBC7
eynaTNDtblG7vqg6Md3g1vkyQEireAkoDxWaj7SoP18xe3XbvTKOT5gCrWnHhRRKZK5x
JPNovaP2z9Uq72EhW1+PO5cceirHxRtf+5mI7k0E8kNI4O2jDPSwdr+fEAa2AS51pFpO
NPcAqe0Ee7FOKrd41mYZw3zFQw/6v9HvKVtqxQpc9zCbLQb1Hc4NDSRm3wNM4YvzSsEi
9CU47r5IhU39Uvb2UfBAO1HudzxsnkEOPKcscJS6LXxUnoTeAO6z/WeZXR7EJgya1tPm
szfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1712509212; x=1713114012;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=ImqPnegsfhSmEKPjHRSu4WjIe+y4DjLFN56t4phfAkg=;
b=AL08Ay02SnrM4IAkOvtvpxvWdiORJopBeNIqpA8psVeUFkLoMw/4ViP8Pj8StEhv/i
1+qHp+DaDNXvJAostvq5Xvef/doB/COJSqV4AecQcHz8Pbrb+QspefiIoVNY+KAz/ByK
TCU4Pk9LV1IKEhuwJw74cqpnlp9UAOlW5n/jV8W2kmntmnTcfZQPzCxCUcsdJf9QdvtH
92+BwnmlZudFJsUiH7BLN8Y1VE8MdHKOveEjLJ3B1TI2n1FEMCJ4KQ3CpixJoLOmswKP
BCV7F5YKQ7KMTF6h3AvES+4hZe2k6Qry4PWWPLiGo2j5RFPF9DYp0nj3eQa6wqdLuwBy
rrJg==
X-Forwarded-Encrypted: i=1;
AJvYcCX8iTKBmYWyRZftS8D3WzFPLgex02/rx3XzU66dQI/jzc/JfnnTN5MP71bkyAfb56Tm+vjsKnDPaUf2NQ0=
X-Gm-Message-State: AOJu0Yz/nTywe2AJzZxKhzuH2/RNe8qBq9im6YkiJqLagbx63ODmjH3X
YAdW+XVNcj9hHGJQNcapMCIM9H2X1BvJzyi3Ud9m/S3itKz431C7zwjFBqNy50c=
X-Google-Smtp-Source: AGHT+IHmDHi2bsS4BKHfisZ8BKbmnPk9EGmgkMTDQImclP7e0VlQxd19P7ZnQ+uFjqWyVYm9xDsftQ==
X-Received: by 2002:a05:6a20:c907:b0:1a7:549e:ab80 with SMTP id
gx7-20020a056a20c90700b001a7549eab80mr5108878pzb.47.1712509208824;
Sun, 07 Apr 2024 10:00:08 -0700 (PDT)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
by smtp.gmail.com with ESMTPSA id
j20-20020aa78014000000b006e6a16acf85sm4866908pfi.87.2024.04.07.10.00.08
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 07 Apr 2024 10:00:08 -0700 (PDT)
Date: Sun, 7 Apr 2024 10:00:08 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= <hofors@lysator.liu.se>
Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com>, Tyler
Retzlaff <roretzla@linux.microsoft.com>, Thomas Monjalon
<thomas@monjalon.net>, Bruce Richardson <bruce.richardson@intel.com>,
dev@dpdk.org
Subject: Re: [PATCH 1/4] latencystats: use alloca instead of vla trivial
Message-ID: <20240407100008.361cb45a@hermes.local>
In-Reply-To: <0c4ba365-94db-46ed-b843-2a70b0948368@lysator.liu.se>
References: <20231107193220.GA15232@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
<1712250913-1977-1-git-send-email-roretzla@linux.microsoft.com>
<1712250913-1977-2-git-send-email-roretzla@linux.microsoft.com>
<98CBD80474FA8B44BF855DF32C47DC35E9F373@smartserver.smartshare.dk>
<0c4ba365-94db-46ed-b843-2a70b0948368@lysator.liu.se>
MIME-Version: 1.0
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Sun, 7 Apr 2024 11:36:59 +0200
Mattias R=C3=B6nnblom <hofors@lysator.liu.se> wrote:
> On 2024-04-06 17:28, Morten Br=C3=B8rup wrote:
> >> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> >> Sent: Thursday, 4 April 2024 19.15
> >>
> >> RFC sample illustrating simple conversion of VLA to alloca().
> >>
> >> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >> --- =20
> >=20
> > [...]
> > =20
> >> --- a/lib/latencystats/rte_latencystats.c
> >> +++ b/lib/latencystats/rte_latencystats.c
> >> @@ -159,7 +159,7 @@ struct latency_stats_nameoff {
> >> {
> >> unsigned int i, cnt =3D 0;
> >> uint64_t now;
> >> - float latency[nb_pkts];
> >> + float *latency =3D alloca(sizeof(float) * nb_pkts); =20
> >=20
> > In cases where we are processing packet bursts, I would prefer introduc=
ing a global #define RTE_MAX_PKT_BURST_SIZE, indicating the max packet burs=
t size supported by libraries and drivers. =20
>=20
> First question: what is meant by a "packet" here? An mbuf? A=20
> network-layer PDU? Something that in some way relates to zero or more=20
> packets, like an rte_event? Or just any object that are sent or receive=20
> of some DPDK API in batches or bursts?
>=20
> Second question: is RTE_MAX_PKT_BURST_SIZE meant as an upper bound, so=20
> no API can consumer or produce a burst larger than this, it does all=20
> APIs literally have to support that burst size.
>=20
> Third question: why not just keep VLAs?
>=20
> > For reference, rte_config.h already has #define RTE_GRAPH_BURST_SIZE 25=
6.
> >=20
> > Such a common define should also be used by functions such as rte_pktmb=
uf_free_bulk(); although it also supports segmented packets, so it must sti=
ll be able to handle more mbufs.
> > https://elixir.bootlin.com/dpdk/v24.03/source/lib/mbuf/rte_mbuf.c#L486
> > =20
Looking at the maths here, calc_lantency can be seriously improved:
- the calc latency is in the fast path. for transmit.
- it is doing floating point math; floating point is much slower than do=
ing
fixed point
- the latency[] array is a temporary, it should be possible to compute
total latency without it.
- it acquires a lock, in order to achieve DPDK level performance of 40 M=
pps, it is
necessary to not do absolute minimum of locking.