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 24DCF43150; Thu, 12 Oct 2023 08:07:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 12619402CB; Thu, 12 Oct 2023 08:07:41 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 42DAC402CB for ; Thu, 12 Oct 2023 08:07:40 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 284C920424; Thu, 12 Oct 2023 08:07:40 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] clarify purpose of empty cache lines X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Oct 2023 08:07:37 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EF3D@smartserver.smartshare.dk> In-Reply-To: <6554142.G0QQBjFxQf@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] clarify purpose of empty cache lines Thread-Index: Adn8nMoiwGatNMzoQryYwpzwqC7/KgAMoYhg References: <20230904084349.12044-1-mb@smartsharesystems.com> <6554142.G0QQBjFxQf@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" Cc: , , , , , , , , 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 > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, 12 October 2023 01.44 >=20 > 04/09/2023 10:43, Morten Br=F8rup: > > /** Force minimum cache line alignment. */ > > #define __rte_cache_min_aligned = __rte_aligned(RTE_CACHE_LINE_MIN_SIZE) > > > > +#define _RTE_CACHE_GUARD_HELPER2(unique) \ > > + char cache_guard_ ## unique[RTE_CACHE_LINE_SIZE * > RTE_CACHE_GUARD_LINES] \ > > + __rte_cache_aligned > > +#define _RTE_CACHE_GUARD_HELPER1(unique) = _RTE_CACHE_GUARD_HELPER2(unique) >=20 > What is the reason for this intermediate helper macro? >=20 > > +/** > > + * Empty cache lines, to guard against false sharing-like effects > > + * on systems with a next-N-lines hardware prefetcher. > > + * > > + * Use as spacing between data accessed by different lcores, > > + * to prevent cache thrashing on hardware with speculative = prefetching. > > + */ > > +#define RTE_CACHE_GUARD _RTE_CACHE_GUARD_HELPER1(__COUNTER__) HELPER1 is required to convert __COUNTER__ to a number before HELPER2 = concatenates it to cache_guard_. If using HELPER2 directly, #define RTE_CACHE_GUARD _RTE_CACHE_GUARD_HELPER2(__COUNTER__) would expand to: char cache_guard___COUNTER__[RTE_CACHE_LINE_SIZE * = RTE_CACHE_GUARD_LINES] __rte_cache_aligned Which is not unique, and would prevent using RTE_CACHE_GUARD multiple = times in the same structure.