Received-SPF: pass (google.com: domain of linux-kernel+bounces-213052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <43c1ec2f-977e-45cd-b974-e943fa880535@intel.com>
Date: Thu, 13 Jun 2024 12:47:33 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH iwl-next 01/12] libeth: add cacheline / struct alignment
 helpers
To: Jakub Kicinski <kuba@kernel.org>
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>
References: <20240528134846.148890-1-aleksander.lobakin@intel.com>
 <20240528134846.148890-2-aleksander.lobakin@intel.com>
 <20240529183409.29a914c2@kernel.org>
From: Alexander Lobakin <aleksander.lobakin@intel.com>
Content-Language: en-US
In-Reply-To: <20240529183409.29a914c2@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S012QXk2aU5LbTlOWThVNHZ2YXlOaWpIdnh1SnZhZzRIZlk3by8vL2Q3aFN4?=
 =?utf-8?B?VmNOS056d1ArWnhtVUtCSUp1L3lxem5TczdmSG82dFpsa1VrakhFeXBiSldo?=
 =?utf-8?B?d3c5Y0FYeVNLZFVTcFBQTG1YU25ISnpMc0krTExGYVZTMXY2VU9ZTmltS3dU?=
 =?utf-8?B?VXRMcGcyOHZqQVhZQVdoTHZvdHdqUldveVRvZTdaMW1XamhXcnBaMjgreERq?=
 =?utf-8?B?ZTI3SUxnVDVwdmR4VUVLOUQ1ZEQ1ckgwSDNrZVZ6L1dDaUV6N0RTUzlzU0JN?=
 =?utf-8?B?dnZ2bktYa2x6ZDZyZ3R1ODdUVlFsUzE5ZndValJNNWVTTmxPM0d6djZXNlFa?=
 =?utf-8?B?QVE0OGdlckJpdUVBTkpnU1lHZFZPQ242d3BlU2hnSHdKNkEzRHZOV293K0Jp?=
 =?utf-8?B?ZXZBQUU3Y0xweXBGbFlzK21mVU54dlBYcHUyTlNIQnd4SHFJQUhxekN4VlIr?=
 =?utf-8?B?VzBndWRGTmNYdFV6VWxMZTN4L296cm1YM01aVkppaWFBWUpHVU1FQ1RRcXFG?=
 =?utf-8?B?Ym1FcVpETnp4S3l1eGRIaGFNN3JoVXJSMnp2Z1ZxZ3ZySy9YMlRSQVN2SjJK?=
 =?utf-8?B?V211MFdqS1Y3NVBtZEk5QTZ3eEo0ZkgwMVZ4ZW5zdHkybHRJdmlUeDVwWXBR?=
 =?utf-8?B?bFpsbFpMdVBPRWxGK04vb080anVrMERUR3pSQW5WVzIweTV6WjZ3Tk9nZmlu?=
 =?utf-8?B?Mk9KK2FBd1l4NTRrNlZ5NnFieEw3VjZWRFM1ZHJvbGI3WlE3SnJnamk0Ym9w?=
 =?utf-8?B?RUxTQ09ZNG1pMGZhVm9HYnRDdVN2NlQ5OU9GTUtSKzhLOVQ1WFh4b0M5NEtz?=
 =?utf-8?B?UGorek1xRFNHcG82OXJRekVnMDVBVzFlWmt1c2QwaVlDL3BXNmE2UVhLMGQ5?=
 =?utf-8?B?Z3FmWWxmNmJPdTM0Vy9qNGRVbUJmTU9oVkZUWmt1LzFkTTNxZnRuTTdJdTN3?=
 =?utf-8?B?TkQ3OVI1d2pvRXl3endUdUd2anN6TFluNWxlcjR0cWtuMk4zbVA4MlNsNXMw?=
 =?utf-8?B?UTdqbjNpUUhNUThwSWNKVnZpUWlDSk1GcGs5aUVLT2R6d2RiZWNZL2tZZFVD?=
 =?utf-8?B?bERUWGtXT1QwVWQ1TkRMOFNzc0JCQlozWXV4TWV2TkZ0QU1NWmtsV3JSWlFE?=
 =?utf-8?B?d0dHV1p0WnU4c2JjMVF5MXZidlZFelhmOUM3ditMM0hCR3pTY1hnM1ptUjQ0?=
 =?utf-8?B?OE5qODNnZUZJRmJvUXBlYWJQdzMwQjR2SWtjWDZaTWZUY1EzdHJYWDRsRUFQ?=
 =?utf-8?B?Zkp3STJrWUNzNlhWVlFsQ0VOaHUrWnljSEJpck1TS2ZKWTNuODgvZTM1eklp?=
 =?utf-8?B?OFpJWGNtaEtxcVN5SjhlVS8vSTFXcnVpbWVtN0tPRWZwaTRLTVdYTUtXVURW?=
 =?utf-8?B?NHl5OUhZUkhMRG8rNkY5c1N4NkI4ai9rWEZXYmNoaVNMUDFYVytHZHZFRjVh?=
 =?utf-8?B?M1hIREs5Z2RJbm15ckxUd0hvc0s2d3MwNndlZ3dCUnE2bmFjRkRXQXE2SFgx?=
 =?utf-8?B?anE2RCtvRmNNSHZYQTJSRFpMNEl6R3ZabW9GNFZLWVdWdTl1czR6eVZOcjM1?=
 =?utf-8?B?WVlLSGtRUERBRmc0YmlQSFlPRjNnR0d1aW1iQU5yd09BalBmckM4QkRTTWxj?=
 =?utf-8?B?MXBLVDN0OVg1cGl4ZG1uK2FwUzhQbUFoSzdhcWpKcjg2dnlPZXBEZmZCcGdy?=
 =?utf-8?B?b2RiMTRoaXNIdjNCN0x6anpRbXEwL2krUVN2KzFSZDhEQ3ZvQ0xBb0FEeEw4?=
 =?utf-8?B?QVZKVVBHY0w5VzhacGFod0dWOXBRSUtrM2NRRk5uQ0xwN2s0ZWFkWWdHNDhj?=
 =?utf-8?B?T3pZU3pEZzF0T2VsRVU0ZFVSWWtKQlNOcUNCaCtVNk9vRWRueDVlTis1OFc5?=
 =?utf-8?B?MjR5YXpRd1BLT0xXdWpIYzBKelZITVMxbjhBdzhpb0xQSmZ6RTI4RFBHM3ly?=
 =?utf-8?B?cU9mZ1JGMTA2VFcyZUZiQUEvMjhSb3pndXYxelZSL3RSV2k1eHVUWnF6cFN5?=
 =?utf-8?B?WU03RUwyRWhNQnJiOFFjU1JkWHJJWEVxM1p5UitSVnZsMDFPR01OUVl6aWRG?=
 =?utf-8?B?dGJoVHBlMnp2TlhHb2szaThEL0xra3ZjZThRbTVYTE9nUWFnZUt2bHB6UHZh?=
 =?utf-8?B?T0FZdS9XRVdmanJiZjV4Uk9JNmpvTG9uMGF4Y1d4eUJRZW5FSFIzdFBSM2R2?=
 =?utf-8?B?K3c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b7539ad7-b8cf-42bc-13de-08dc8b964b1d
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB8718.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2024 10:48:00.3345
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1vcf7dB9TN3OB1cLHoXwtYNHKiqN37uN/auhjLmdGuQlz1zdrsDwbwq/I4vM92P+XP9kclZ5QJFjWftKcleXTjQxNdMOTSd6wSt77L1GaSE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7787
X-OriginatorOrg: intel.com

From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 29 May 2024 18:34:09 -0700

> On Tue, 28 May 2024 15:48:35 +0200 Alexander Lobakin wrote:
>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>> index 95a59ac78f82..d0cf9a2d82de 100755
>> --- a/scripts/kernel-doc
>> +++ b/scripts/kernel-doc
>> @@ -1155,6 +1155,7 @@ sub dump_struct($$) {
>>          $members =~ s/\bstruct_group_attr\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
>>          $members =~ s/\bstruct_group_tagged\s*\(([^,]*),([^,]*),/struct $1 $2; STRUCT_GROUP(/gos;
>>          $members =~ s/\b__struct_group\s*\(([^,]*,){3}/STRUCT_GROUP(/gos;
>> +        $members =~ s/\blibeth_cacheline_group\s*\(([^,]*,)/struct { } $1; STRUCT_GROUP(/gos;
>>          $members =~ s/\bSTRUCT_GROUP(\(((?:(?>[^)(]+)|(?1))*)\))[^;]*;/$2/gos;
>>  
>>          my $args = qr{([^,)]+)};
> 
> 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)

> 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.
Why is it too much if we have the same stuff for the netdev core?

Thanks,
Olek