From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: Alexander Lobakin <aleksander.lobakin@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Mina Almasry <almasrymina@google.com>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH iwl-next v2 03/14] libeth: add cacheline / struct layout assertion helpers
Date: Thu, 20 Jun 2024 15:53:36 +0200 [thread overview]
Message-ID: <20240620135347.3006818-4-aleksander.lobakin@intel.com> (raw)
In-Reply-To: <20240620135347.3006818-1-aleksander.lobakin@intel.com>
Add helpers to assert struct field layout, a bit more crazy and
networking-specific than in <linux/cache.h>. They assume you have
3 CL-aligned groups (read-mostly, read-write, cold) in a struct
you want to assert, and nothing besides them.
For 64-bit with 64-byte cachelines, the assertions are as strict
as possible, as the size can then be easily predicted.
For the rest, make sure they don't cross the specified bound.
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
---
include/net/libeth/cache.h | 66 ++++++++++++++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
create mode 100644 include/net/libeth/cache.h
diff --git a/include/net/libeth/cache.h b/include/net/libeth/cache.h
new file mode 100644
index 000000000000..bdb0c043ce61
--- /dev/null
+++ b/include/net/libeth/cache.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright (C) 2024 Intel Corporation */
+
+#ifndef __LIBETH_CACHE_H
+#define __LIBETH_CACHE_H
+
+#include <linux/cache.h>
+
+/**
+ * libeth_cacheline_group_assert - make sure cacheline group size is expected
+ * @type: type of the structure containing the group
+ * @grp: group name inside the struct
+ * @sz: expected group size
+ */
+#if defined(CONFIG_64BIT) && SMP_CACHE_BYTES == 64
+#define libeth_cacheline_group_assert(type, grp, sz) \
+ static_assert(offsetof(type, __cacheline_group_end__##grp) - \
+ offsetofend(type, __cacheline_group_begin__##grp) == \
+ (sz))
+#define __libeth_cacheline_struct_assert(type, sz) \
+ static_assert(sizeof(type) == (sz))
+#else /* !CONFIG_64BIT || SMP_CACHE_BYTES != 64 */
+#define libeth_cacheline_group_assert(type, grp, sz) \
+ static_assert(offsetof(type, __cacheline_group_end__##grp) - \
+ offsetofend(type, __cacheline_group_begin__##grp) <= \
+ (sz))
+#define __libeth_cacheline_struct_assert(type, sz) \
+ static_assert(sizeof(type) <= (sz))
+#endif /* !CONFIG_64BIT || SMP_CACHE_BYTES != 64 */
+
+#define __libeth_cls1(sz1) SMP_CACHE_ALIGN(sz1)
+#define __libeth_cls2(sz1, sz2) (SMP_CACHE_ALIGN(sz1) + SMP_CACHE_ALIGN(sz2))
+#define __libeth_cls3(sz1, sz2, sz3) \
+ (SMP_CACHE_ALIGN(sz1) + SMP_CACHE_ALIGN(sz2) + SMP_CACHE_ALIGN(sz3))
+#define __libeth_cls(...) \
+ CONCATENATE(__libeth_cls, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)
+
+/**
+ * libeth_cacheline_struct_assert - make sure CL-based struct size is expected
+ * @type: type of the struct
+ * @...: from 1 to 3 CL group sizes (read-mostly, read-write, cold)
+ *
+ * When a struct contains several CL groups, it's difficult to predict its size
+ * on different architectures. The macro instead takes sizes of all of the
+ * groups the structure contains and generates the final struct size.
+ */
+#define libeth_cacheline_struct_assert(type, ...) \
+ __libeth_cacheline_struct_assert(type, __libeth_cls(__VA_ARGS__)); \
+ static_assert(__alignof(type) >= SMP_CACHE_BYTES)
+
+/**
+ * libeth_cacheline_set_assert - make sure CL-based struct layout is expected
+ * @type: type of the struct
+ * @ro: expected size of the read-mostly group
+ * @rw: expected size of the read-write group
+ * @c: expected size of the cold group
+ *
+ * Check that each group size is expected and then do final struct size check.
+ */
+#define libeth_cacheline_set_assert(type, ro, rw, c) \
+ libeth_cacheline_group_assert(type, read_mostly, ro); \
+ libeth_cacheline_group_assert(type, read_write, rw); \
+ libeth_cacheline_group_assert(type, cold, c); \
+ libeth_cacheline_struct_assert(type, ro, rw, c)
+
+#endif /* __LIBETH_CACHE_H */
--
2.45.2
next prev parent reply other threads:[~2024-06-20 13:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 13:53 [PATCH iwl-next v2 00/14] idpf: XDP chapter I: convert Rx to libeth Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin,end}_aligned() (+ couple more) Alexander Lobakin
2024-06-20 15:15 ` Przemek Kitszel
2024-06-25 10:24 ` Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 02/14] page_pool: use __cacheline_group_{begin,end}_aligned() Alexander Lobakin
2024-06-20 13:53 ` Alexander Lobakin [this message]
2024-06-20 13:53 ` [PATCH iwl-next v2 04/14] idpf: stop using macros for accessing queue descriptors Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 05/14] idpf: split &idpf_queue into 4 strictly-typed queue structures Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 06/14] idpf: avoid bloating &idpf_q_vector with big %NR_CPUS Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 07/14] idpf: strictly assert cachelines of queue and queue vector structures Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 08/14] idpf: merge singleq and splitq &net_device_ops Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 09/14] idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 10/14] idpf: reuse libeth's definitions of parsed ptype structures Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 11/14] idpf: remove legacy Page Pool Ethtool stats Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 12/14] libeth: support different types of buffers for Rx Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 13/14] idpf: convert header split mode to libeth + napi_build_skb() Alexander Lobakin
2024-06-20 13:53 ` [PATCH iwl-next v2 14/14] idpf: use libeth Rx buffer management for payload buffer Alexander Lobakin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240620135347.3006818-4-aleksander.lobakin@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=almasrymina@google.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®