All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Mina Almasry <almasrymina@google.com>,
	nex.sw.ncis.osdt.itp.upstreaming@intel.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Eric Dumazet <edumazet@google.com>,
	intel-wired-lan@lists.osuosl.org,
	Jakub Kicinski <kuba@kernel.org>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin, end}_aligned() (+ couple more)
Date: Tue, 25 Jun 2024 12:24:23 +0200	[thread overview]
Message-ID: <d6bc563e-e700-421f-ae19-ed254ed01786@intel.com> (raw)
In-Reply-To: <38875747-d728-4784-b8da-057d999e1fac@intel.com>

From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Date: Thu, 20 Jun 2024 17:15:53 +0200

> On 6/20/24 15:53, Alexander Lobakin wrote:
>> __cacheline_group_begin(), unfortunately, doesn't align the group
>> anyhow. If it is wanted, then you need to do something like
>>
>> __cacheline_group_begin(grp) __aligned(ALIGN)
>>
>> which isn't really convenient nor compact.
>> Add the _aligned() counterparts to align the groups automatically to
>> either the specified alignment (optional) or ``SMP_CACHE_BYTES``.
>> Note that the actual struct layout will then be (on x64 with 64-byte CL):
>>
>> struct x {
>>     u32 y;                // offset 0, size 4, padding 56
>>     __cacheline_group_begin__grp;    // offset 64, size 0
>>     u32 z;                // offset 64, size 4, padding 4
>>     __cacheline_group_end__grp;    // offset 72, size 0
>>     __cacheline_group_pad__grp;    // offset 72, size 0, padding 56
>>     u32 w;                // offset 128
>> };
>>
>> The end marker is aligned to long, so that you can assert the struct
>> size more strictly, but the offset of the next field in the structure
>> will be aligned to the group alignment, so that the next field won't
>> fall into the group it's not intended to.
>>
>> Add __LARGEST_ALIGN definition and LARGEST_ALIGN() macro.
>> __LARGEST_ALIGN is the value to which the compilers align fields when
>> __aligned_largest is specified. Sometimes, it might be needed to get
>> this value outside of variable definitions. LARGEST_ALIGN() is macro
>> which just aligns a value to __LARGEST_ALIGN.
>> Also add SMP_CACHE_ALIGN(), similar to L1_CACHE_ALIGN(), but using
>> ``SMP_CACHE_BYTES`` instead of ``L1_CACHE_BYTES`` as the former
>> also accounts L2, needed in some cases.
>>
>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
>> ---
>>   include/linux/cache.h | 59 +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 59 insertions(+)
>>
> 
> [...]
> 
>> +/**
>> + * __cacheline_group_begin_aligned - declare an aligned group start
>> + * @GROUP: name of the group
>> + * @...: optional group alignment
> 
> didn't know that you could document "..." :)
> 
>> + *
>> + * The following block inside a struct:
>> + *
>> + *    __cacheline_group_begin_aligned(grp);
>> + *    field a;
>> + *    field b;
>> + *    __cacheline_group_end_aligned(grp);
>> + *
>> + * will always be aligned to either the specified alignment or
>> + * ``SMP_CACHE_BYTES``.
>> + */
>> +#define __cacheline_group_begin_aligned(GROUP, ...)        \
>> +    __cacheline_group_begin(GROUP)                \
>> +    __aligned((__VA_ARGS__ + 0) ? : SMP_CACHE_BYTES)
> 
> nice trick :) +0

The usual way to handle varargs. However, this one:

	__cacheline_group_begin_aligned(grp, 63 & 31);

will trigger a compiler warning as it expands to

	__aligned(63 & 31 + 0)

The compilers don't like bitops and arithmetic ops not separated by
parenthesis even in such simple case =\

Thanks,
Olek

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	<intel-wired-lan@lists.osuosl.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.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: Re: [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin,end}_aligned() (+ couple more)
Date: Tue, 25 Jun 2024 12:24:23 +0200	[thread overview]
Message-ID: <d6bc563e-e700-421f-ae19-ed254ed01786@intel.com> (raw)
In-Reply-To: <38875747-d728-4784-b8da-057d999e1fac@intel.com>

From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Date: Thu, 20 Jun 2024 17:15:53 +0200

> On 6/20/24 15:53, Alexander Lobakin wrote:
>> __cacheline_group_begin(), unfortunately, doesn't align the group
>> anyhow. If it is wanted, then you need to do something like
>>
>> __cacheline_group_begin(grp) __aligned(ALIGN)
>>
>> which isn't really convenient nor compact.
>> Add the _aligned() counterparts to align the groups automatically to
>> either the specified alignment (optional) or ``SMP_CACHE_BYTES``.
>> Note that the actual struct layout will then be (on x64 with 64-byte CL):
>>
>> struct x {
>>     u32 y;                // offset 0, size 4, padding 56
>>     __cacheline_group_begin__grp;    // offset 64, size 0
>>     u32 z;                // offset 64, size 4, padding 4
>>     __cacheline_group_end__grp;    // offset 72, size 0
>>     __cacheline_group_pad__grp;    // offset 72, size 0, padding 56
>>     u32 w;                // offset 128
>> };
>>
>> The end marker is aligned to long, so that you can assert the struct
>> size more strictly, but the offset of the next field in the structure
>> will be aligned to the group alignment, so that the next field won't
>> fall into the group it's not intended to.
>>
>> Add __LARGEST_ALIGN definition and LARGEST_ALIGN() macro.
>> __LARGEST_ALIGN is the value to which the compilers align fields when
>> __aligned_largest is specified. Sometimes, it might be needed to get
>> this value outside of variable definitions. LARGEST_ALIGN() is macro
>> which just aligns a value to __LARGEST_ALIGN.
>> Also add SMP_CACHE_ALIGN(), similar to L1_CACHE_ALIGN(), but using
>> ``SMP_CACHE_BYTES`` instead of ``L1_CACHE_BYTES`` as the former
>> also accounts L2, needed in some cases.
>>
>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
>> ---
>>   include/linux/cache.h | 59 +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 59 insertions(+)
>>
> 
> [...]
> 
>> +/**
>> + * __cacheline_group_begin_aligned - declare an aligned group start
>> + * @GROUP: name of the group
>> + * @...: optional group alignment
> 
> didn't know that you could document "..." :)
> 
>> + *
>> + * The following block inside a struct:
>> + *
>> + *    __cacheline_group_begin_aligned(grp);
>> + *    field a;
>> + *    field b;
>> + *    __cacheline_group_end_aligned(grp);
>> + *
>> + * will always be aligned to either the specified alignment or
>> + * ``SMP_CACHE_BYTES``.
>> + */
>> +#define __cacheline_group_begin_aligned(GROUP, ...)        \
>> +    __cacheline_group_begin(GROUP)                \
>> +    __aligned((__VA_ARGS__ + 0) ? : SMP_CACHE_BYTES)
> 
> nice trick :) +0

The usual way to handle varargs. However, this one:

	__cacheline_group_begin_aligned(grp, 63 & 31);

will trigger a compiler warning as it expands to

	__aligned(63 & 31 + 0)

The compilers don't like bitops and arithmetic ops not separated by
parenthesis even in such simple case =\

Thanks,
Olek

  reply	other threads:[~2024-06-25 10:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 13:53 [Intel-wired-lan] [PATCH iwl-next v2 00/14] idpf: XDP chapter I: convert Rx to libeth Alexander Lobakin
2024-06-20 13:53 ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin, end}_aligned() (+ couple more) Alexander Lobakin
2024-06-20 13:53   ` [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin,end}_aligned() " Alexander Lobakin
2024-06-20 15:15   ` [Intel-wired-lan] [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin, end}_aligned() " Przemek Kitszel
2024-06-20 15:15     ` [PATCH iwl-next v2 01/14] cache: add __cacheline_group_{begin,end}_aligned() " Przemek Kitszel
2024-06-25 10:24     ` Alexander Lobakin [this message]
2024-06-25 10:24       ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 02/14] page_pool: use __cacheline_group_{begin, end}_aligned() 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 ` [Intel-wired-lan] [PATCH iwl-next v2 03/14] libeth: add cacheline / struct layout assertion helpers Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 04/14] idpf: stop using macros for accessing queue descriptors Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 05/14] idpf: split &idpf_queue into 4 strictly-typed queue structures Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 06/14] idpf: avoid bloating &idpf_q_vector with big %NR_CPUS Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 07/14] idpf: strictly assert cachelines of queue and queue vector structures Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 08/14] idpf: merge singleq and splitq &net_device_ops Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 09/14] idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 10/14] idpf: reuse libeth's definitions of parsed ptype structures Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 11/14] idpf: remove legacy Page Pool Ethtool stats Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 12/14] libeth: support different types of buffers for Rx Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 13/14] idpf: convert header split mode to libeth + napi_build_skb() Alexander Lobakin
2024-06-20 13:53   ` Alexander Lobakin
2024-06-20 13:53 ` [Intel-wired-lan] [PATCH iwl-next v2 14/14] idpf: use libeth Rx buffer management for payload buffer Alexander Lobakin
2024-06-20 13:53   ` 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=d6bc563e-e700-421f-ae19-ed254ed01786@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.