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 9900346075; Tue, 14 Jan 2025 17:11:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F72140299; Tue, 14 Jan 2025 17:11:38 +0100 (CET) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 8302240298 for ; Tue, 14 Jan 2025 17:11:36 +0100 (CET) Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-2ee709715d9so7821044a91.3 for ; Tue, 14 Jan 2025 08:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1736871095; x=1737475895; 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=LvHlA/dfcZMq7sp0KprmapbF6T8LzQjcy53CqI/bhXI=; b=Amnq5amwD1cXhyzgoM2JhaR5LGzxBxYpgM3dcBj4GNoY6BuL++/uY9YAV+vLtpmTys jSCUuwZ130YCTdB5r9PUw5cz9kriMJnAdSfiUDPcJUGYbZPSXPZnCTq/qdtR2JwO9TDH oXS262hGvRCq8LiutLDHWaK7eRDlhoDbXE7YevmtzPaeDUYBJAOMRwuNjtFAT6uDZ9fk YZLiA/Jl5I831ugwwSWP1iCtTUji4RXy+SlF8AADMQbQxpQ0NiKYZ9J3Vdo3rHoVHnHw AjPwXKrjGSaPHcesSxL1zDC8Anvj1qWg0092S4w2W5LYYO/rSJ3fzr4CdpDjArorSsMg dyYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736871095; x=1737475895; 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=LvHlA/dfcZMq7sp0KprmapbF6T8LzQjcy53CqI/bhXI=; b=GJ4u5QXo0fRZlAdKIm3w44soHvLMLYPeTl4pOfc7CdWY//ued+V9myA+jHS5fdjjsz qVaGveyKc4n+QNeRpc36Lg2s95YQ1q970vTEgyhSSAlnWVZ7vWs/Gf29bfNm3479HVt2 qgg2P9awtTvEA30O2P+Sdb7dq0qAis2/Sth1pBBVkjlltiDs33oCbsMnCk+m/rRjtjmq PNxBBO6gKy0pqCPlJD2LEc28ldLyCJ+ZpsFqiCJCRMX9jB/v3tXcmBrGJYjXCsIbGdtf wSlNZzPnektaOh9YEZBW/KOqrd+OUr2UmCOJtkqFuyDDEqHmGafxeNR4c3ELOGPrxr/x DQtA== X-Gm-Message-State: AOJu0YxLfq0ougP1FoN0esV5Gmvvg69CpOwBKwTPk6IEHoHxuBFzVjcX 4JRwa1zfnWT34yPEfNMKsf+RBznvIQ3gU38YymqABlap7oIPjwkRfVuL6nQ0/O8= X-Gm-Gg: ASbGnctRWsNs4b8oEEMOsdtCV5dfi2wDN9eyAS4DrTkJm9JbgR5idKAgn+n48/RzJEu f5B5SA4ObMUyV7CSajbW3iw4YV2MmYNNef7cLCzK2d+LXtt238LKnlRpfmwmdemgIeBrbfIIJ0e BYLcOLot5cPgPeCTwYHMJwZv3KTs4vJlErsYtINyfUwx4lTiA9rQt5opctZ4ciPdiixxJq8XGq2 Sbe7M5pLRn9DINwDwRmrYvfIDMFRsIOGVtESaC8lVNRegQzakVizRnK+kMXJIl3vvBUuPvQHp6c Q+bekvyXzrKVzKxHjWZMCmFSUv6Kblad7w== X-Google-Smtp-Source: AGHT+IFVb8zCPCmdnfNENqUkxDr9ZxBzWHDLA5XMq6pGjWwX+ixc2OCzi09SA8qdRfhQhVnlkv94/Q== X-Received: by 2002:a17:90b:1f92:b0:2ee:693e:ed7a with SMTP id 98e67ed59e1d1-2f548f429e3mr35626947a91.35.1736871095037; Tue, 14 Jan 2025 08:11:35 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2f54a2b0380sm11685689a91.27.2025.01.14.08.11.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 08:11:34 -0800 (PST) Date: Tue, 14 Jan 2025 08:11:32 -0800 From: Stephen Hemminger To: huangdengdui Cc: , , , , , , Subject: Re: [PATCH] examples/l3fwd: add option to set refetch offset Message-ID: <20250114081132.7cb10641@hermes.local> In-Reply-To: <20250114080752.2615e68d@hermes.local> References: <20241225075302.353013-1-huangdengdui@huawei.com> <20250110093715.4044681-1-huangdengdui@huawei.com> <20250110092036.23a762dd@hermes.local> <59587382-d90d-4141-936a-6af5fed5c859@huawei.com> <20250114080752.2615e68d@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 14 Jan 2025 08:07:52 -0800 Stephen Hemminger wrote: > On Tue, 14 Jan 2025 17:22:08 +0800 > huangdengdui wrote: > > > On 2025/1/11 1:20, Stephen Hemminger wrote: > > > This will make it slower for many platforms. > > > GCC will unroll a loop of fixed small size, which is what we want. > > > > Do you mean to replace option with a macro? > > But most of prefetch_offset are used with the nb_rx, So using macros is the same as using options. > > > > const int32_t k = RTE_ALIGN_FLOOR(nb_rx, FWDSTEP); > > for (j = 0; j != k; j += FWDSTEP) { > > for (i = 0, pos = j + prefetch_offset; > > i < FWDSTEP && pos < k; i++, pos++) > > rte_prefetch0(rte_pktmbuf_mtod(pkts_burst[pos], void *)); > > processx4_step1(&pkts_burst[j], &dip, &ipv4_flag); > > processx4_step2(qconf, dip, ipv4_flag, portid, > > &pkts_burst[j], &dst_port[j]); > > if (do_step3) > > processx4_step3(&pkts_burst[j], &dst_port[j]); > > } > > > > The option can dynamically adjust the prefetch window, which makes it easier to find the prefetch window for a HW platform. > > So I think it's better to use option. > > The tradeoff is that loop unrolling most often is only done on small fix sized loops. > And the cost of a loop with variable small values (branch prediction) is high enough that it > could make things slower. > > Prefetching is a balancing act, and more is not better especially on real workloads. You might also want to look at the quad loop model used in VPP for prefetching. https://my-vpp-docs.readthedocs.io/en/latest/gettingstarted/developers/vnet.html