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 DFFE046075; Tue, 14 Jan 2025 17:07:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D3E5440299; Tue, 14 Jan 2025 17:07:57 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id 28ED840298 for ; Tue, 14 Jan 2025 17:07:56 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-21636268e43so133289645ad.2 for ; Tue, 14 Jan 2025 08:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1736870875; x=1737475675; 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=pVCdjWwOsPFtQHYTOZl1MqYKhG9W9E8C94dpesSdkUc=; b=aGJbWsxrcmCKIJSVZN2qzF7N0LMX3UgbWu5Rv05ipHyZmz2kFHhYIWWEAq8VSaHOkX eS7itFR0usAatC/uLY5uiy7pGJEJKytWqkuMwVmz/cbX/zp7IztQnAAYqdtjjySZPFTG SGulDRS/+QHIOG7ehNAj+zyjBoIhpvldaIKO9WGKEPriXqTe73E+tspKcTw18OgJ886z xGqgRX+FzwKZmHWlHd9/GNzy2HxLqpk0RFKYKrVr9AKt8Fadu8mFfKpfUNFRuiX+jECC hmQLDLMam17bmvKUlQP7L8XOEUApIkup0+/WhJPBZfjmY9KJ6mY5HgBkOBsnyPiDqdsA VFww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736870875; x=1737475675; 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=pVCdjWwOsPFtQHYTOZl1MqYKhG9W9E8C94dpesSdkUc=; b=xMDU3Ay0mihhO9sfV60FgiaXpRAO1G3Pk0WX+pMf1ahR2hir4TkMjFe2ikxtiuCJgs DPmonkrrdp7g5rjzGncdqfAti7U2m9jBmb5M5aUru2MrKN0YZ/x0C6UqwS67bksddRw5 AIBMjFsAStrnNqP2r3ppoO3HQU0HHsYVELNt1atBQvnV0xpoR80nAVkfMPm8pJ7LyKEz zLJObDd6Lq2kXsw/Jl0IJsx1sFHkHKFIzYYF6kQTrpduU6q/sAusR5hPm1NAAmoazJOs zPSek++ve2yF1FiWwLXtzSOsGqjx43bQ3X627GBjg4Yq0raXVvW3xW9cS1ycbNTvTNmZ Tlnw== X-Gm-Message-State: AOJu0YzDp9umu3EdzT9SrUlk9Ra39jWeewo/oAo3hiV2ViU9UkEvu+hH 0OQe+VAfyuH6EpcWbGGaVYA5RN0K+u8pMEsQ9NW9Y7ZDvA+1ZBwdo40TW+FJzwc= X-Gm-Gg: ASbGncvoRm1t1n61oviSYp8mQwD7sT/+6Zxq9jsJDyg42qfW/feZLOUCwk3Zq6rXsTN Tc6vrMGMbsk1Xivlw8XtOCdI9pf3Fhc6jBTh2cnjozZpgO+M1h+JYJ8a3xqEx36YRObi6i0l2pL l8vYzZJgrT8gEVXGpcQaTi849gMPQzBN+JIG4jGsKDEadxou0BLYh4NbqRwaDQMlQfgZii55Y1k eOAUV45RVkzWQq1yEchZGUyIsFasJCEyt0tOCkVdAfyGpOE7rvDkiCbL8GDY16Byst6cKyQ8H74 4FJbzzcK5zHkmIQobtbYn44exAPMrNnAjw== X-Google-Smtp-Source: AGHT+IHz8BArJc1LdmJJo+42VEwKoMcz/IYKwFgSd+Q24w70zFJk/hHHi2GGqO6277jHpdEzW+2P4w== X-Received: by 2002:a05:6a00:918b:b0:725:ef4b:de33 with SMTP id d2e1a72fcca58-72d21e1ac75mr34957934b3a.0.1736870874994; Tue, 14 Jan 2025 08:07:54 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-a319772a5a8sm8430189a12.44.2025.01.14.08.07.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 08:07:54 -0800 (PST) Date: Tue, 14 Jan 2025 08:07:52 -0800 From: Stephen Hemminger To: huangdengdui Cc: , , , , , , Subject: Re: [PATCH] examples/l3fwd: add option to set refetch offset Message-ID: <20250114080752.2615e68d@hermes.local> In-Reply-To: <59587382-d90d-4141-936a-6af5fed5c859@huawei.com> References: <20241225075302.353013-1-huangdengdui@huawei.com> <20250110093715.4044681-1-huangdengdui@huawei.com> <20250110092036.23a762dd@hermes.local> <59587382-d90d-4141-936a-6af5fed5c859@huawei.com> 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 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.