All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Mina Almasry <almasrymina@google.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Eric Dumazet <edumazet@google.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	nex.sw.ncis.osdt.itp.upstreaming@intel.com,
	intel-wired-lan@lists.osuosl.org, Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next 01/12] libeth: add cacheline / struct alignment helpers
Date: Thu, 13 Jun 2024 06:47:06 -0700	[thread overview]
Message-ID: <20240613064706.15f26159@kernel.org> (raw)
In-Reply-To: <43c1ec2f-977e-45cd-b974-e943fa880535@intel.com>

On Thu, 13 Jun 2024 12:47:33 +0200 Alexander Lobakin wrote:
> > Having per-driver grouping defines is a no-go.  
> 
> Without it, kdoc warns when I want to describe group fields =\
> 
> > Do you need the defines in the first place?  
> 
> They allow to describe CLs w/o repeating boilerplates like
> 
> 	cacheline_group_begin(blah) __aligned(blah)
> 	fields
> 	cacheline_group_end(blah)

And you assert that your boilerplate is somehow nicer than this?
See my reply to Przemek, I don't think so, and neither do other
maintainers, judging by how the socket grouping was done.
You can add new markers to include the align automatically too, etc.

> > Are you sure the assert you're adding are not going to explode
> > on some weird arch? Honestly, patch 5 feels like a little too  
> 
> I was adjusting and testing it a lot and CI finally started building
> every arch with no issues some time ago, so yes, I'm sure.
> 64-byte CL on 64-bit arch behaves the same everywhere, so the assertions
> for it can be more strict. On other arches, the behaviour is the same as
> how Eric asserts netdev cachelines in the core code.
> 
> > much for a driver..  
> 
> We had multiple situations when our team were optimizing the structure
> layout and then someone added a new field and messed up the layout
> again. So I ended up with strict assertions.

I understand. Not 100% sure I agree but depends on the team, so okay.

> Why is it too much if we have the same stuff for the netdev core?

But we didn't add tcp_* macros and sock_* macros etc.
Improve the stuff in cache.h is you think its worth it.
And no struct_groups() please.

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.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 01/12] libeth: add cacheline / struct alignment helpers
Date: Thu, 13 Jun 2024 06:47:06 -0700	[thread overview]
Message-ID: <20240613064706.15f26159@kernel.org> (raw)
In-Reply-To: <43c1ec2f-977e-45cd-b974-e943fa880535@intel.com>

On Thu, 13 Jun 2024 12:47:33 +0200 Alexander Lobakin wrote:
> > Having per-driver grouping defines is a no-go.  
> 
> Without it, kdoc warns when I want to describe group fields =\
> 
> > Do you need the defines in the first place?  
> 
> They allow to describe CLs w/o repeating boilerplates like
> 
> 	cacheline_group_begin(blah) __aligned(blah)
> 	fields
> 	cacheline_group_end(blah)

And you assert that your boilerplate is somehow nicer than this?
See my reply to Przemek, I don't think so, and neither do other
maintainers, judging by how the socket grouping was done.
You can add new markers to include the align automatically too, etc.

> > Are you sure the assert you're adding are not going to explode
> > on some weird arch? Honestly, patch 5 feels like a little too  
> 
> I was adjusting and testing it a lot and CI finally started building
> every arch with no issues some time ago, so yes, I'm sure.
> 64-byte CL on 64-bit arch behaves the same everywhere, so the assertions
> for it can be more strict. On other arches, the behaviour is the same as
> how Eric asserts netdev cachelines in the core code.
> 
> > much for a driver..  
> 
> We had multiple situations when our team were optimizing the structure
> layout and then someone added a new field and messed up the layout
> again. So I ended up with strict assertions.

I understand. Not 100% sure I agree but depends on the team, so okay.

> Why is it too much if we have the same stuff for the netdev core?

But we didn't add tcp_* macros and sock_* macros etc.
Improve the stuff in cache.h is you think its worth it.
And no struct_groups() please.

  reply	other threads:[~2024-06-13 13:47 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28 13:48 [Intel-wired-lan] [PATCH iwl-next 00/12] idpf: XDP chapter I: convert Rx to libeth Alexander Lobakin
2024-05-28 13:48 ` Alexander Lobakin
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 01/12] libeth: add cacheline / struct alignment helpers Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-30  1:34   ` [Intel-wired-lan] " Jakub Kicinski
2024-05-30  1:34     ` Jakub Kicinski
2024-06-12 10:07     ` [Intel-wired-lan] " Przemek Kitszel
2024-06-12 10:07       ` Przemek Kitszel
2024-06-12 20:55       ` [Intel-wired-lan] " Jakub Kicinski
2024-06-12 20:55         ` Jakub Kicinski
2024-06-13 10:47     ` [Intel-wired-lan] " Alexander Lobakin
2024-06-13 10:47       ` Alexander Lobakin
2024-06-13 13:47       ` Jakub Kicinski [this message]
2024-06-13 13:47         ` Jakub Kicinski
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 02/12] idpf: stop using macros for accessing queue descriptors Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 03/12] idpf: split &idpf_queue into 4 strictly-typed queue structures Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-06-01  8:53   ` [Intel-wired-lan] " Simon Horman
2024-06-01  8:53     ` Simon Horman
2024-06-13 11:03     ` [Intel-wired-lan] " Alexander Lobakin
2024-06-13 11:03       ` Alexander Lobakin
2024-06-15  7:32       ` [Intel-wired-lan] " Simon Horman
2024-06-15  7:32         ` Simon Horman
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 04/12] idpf: avoid bloating &idpf_q_vector with big %NR_CPUS Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:36   ` [Intel-wired-lan] " Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 05/12] idpf: strictly assert cachelines of queue and queue vector structures Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:43   ` [Intel-wired-lan] " Jacob Keller
2024-06-12 13:03     ` Alexander Lobakin
2024-06-12 13:03       ` Alexander Lobakin
2024-06-12 13:08       ` Alexander Lobakin
2024-06-12 13:08         ` Alexander Lobakin
2024-06-12 22:42         ` Jacob Keller
2024-06-12 22:42           ` Jacob Keller
2024-06-12 22:40       ` Jacob Keller
2024-06-12 22:40         ` Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 06/12] idpf: merge singleq and splitq &net_device_ops Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:44   ` [Intel-wired-lan] " Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 07/12] idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:47   ` [Intel-wired-lan] " Jacob Keller
2024-06-12 13:15     ` Alexander Lobakin
2024-06-12 22:43       ` Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 08/12] idpf: reuse libeth's definitions of parsed ptype structures Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:49   ` [Intel-wired-lan] " Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 09/12] idpf: remove legacy Page Pool Ethtool stats Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-29  0:52   ` [Intel-wired-lan] " Jacob Keller
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 10/12] libeth: support different types of buffers for Rx Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 11/12] idpf: convert header split mode to libeth + napi_build_skb() Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-05-30  1:40   ` [Intel-wired-lan] " Jakub Kicinski
2024-05-30  1:40     ` Jakub Kicinski
2024-06-13 10:58     ` [Intel-wired-lan] " Alexander Lobakin
2024-06-13 10:58       ` Alexander Lobakin
2024-05-30 13:46   ` [Intel-wired-lan] " Willem de Bruijn
2024-05-30 13:46     ` Willem de Bruijn
2024-06-17 11:06     ` [Intel-wired-lan] " Alexander Lobakin
2024-06-17 11:06       ` Alexander Lobakin
2024-06-17 18:13       ` [Intel-wired-lan] " Willem de Bruijn
2024-06-17 18:13         ` Willem de Bruijn
2024-06-20 12:46         ` [Intel-wired-lan] " Alexander Lobakin
2024-06-20 12:46           ` Alexander Lobakin
2024-06-20 16:29           ` [Intel-wired-lan] " Willem de Bruijn
2024-06-20 16:29             ` Willem de Bruijn
2024-05-28 13:48 ` [Intel-wired-lan] [PATCH iwl-next 12/12] idpf: use libeth Rx buffer management for payload buffer Alexander Lobakin
2024-05-28 13:48   ` Alexander Lobakin
2024-06-01  9:08   ` [Intel-wired-lan] " Simon Horman
2024-06-01  9:08     ` Simon Horman
2024-06-13 11:05     ` [Intel-wired-lan] " Alexander Lobakin
2024-06-13 11:05       ` Alexander Lobakin
2024-06-15  7:35       ` [Intel-wired-lan] " Simon Horman
2024-06-15  7:35         ` Simon Horman

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=20240613064706.15f26159@kernel.org \
    --to=kuba@kernel.org \
    --cc=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=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
    --cc=pabeni@redhat.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.