[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f86b27c-8d5c-4df9-8d8c-91edb01b0b79@intel.com>
Date: Mon, 30 Sep 2024 15:10:41 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>, Joe Damato
<jdamato@...tly.com>
CC: <netdev@...r.kernel.org>, Tony Nguyen <anthony.l.nguyen@...el.com>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Jakub
Kicinski" <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, "moderated
list:INTEL ETHERNET DRIVERS" <intel-wired-lan@...ts.osuosl.org>, open list
<linux-kernel@...r.kernel.org>, Simon Horman <horms@...nel.org>
Subject: Re: [RFC net-next 1/1] idpf: Don't hard code napi_struct size
On 9/30/24 14:38, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@...el.com>
> Date: Mon, 30 Sep 2024 14:33:45 +0200
>
>> From: Joe Damato <jdamato@...tly.com>
>> Date: Wed, 25 Sep 2024 18:00:17 +0000
> struct napi_struct doesn't have any such fields and doesn't depend on
> the kernel configuration, that's why it's hardcoded.
> Please don't change that, just adjust the hardcoded values when needed.
This is the crucial point, and I agree with Olek.
If you will find it more readable/future proof, feel free to add
comments like /* napi_struct */ near their "400" part in the hardcode.
Side note: you could just run this as a part of your netdev series,
given you will properly CC.
Powered by blists - more mailing lists