[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250528172306.18c1482a@kernel.org>
Date: Wed, 28 May 2025 17:23:06 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
pabeni@...hat.com, edumazet@...gle.com, andrew+netdev@...n.ch,
netdev@...r.kernel.org, Alexander Lobakin <aleksander.lobakin@...el.com>,
maciej.fijalkowski@...el.com, magnus.karlsson@...el.com,
michal.kubiak@...el.com, przemyslaw.kitszel@...el.com, ast@...nel.org,
daniel@...earbox.net, hawk@...nel.org, john.fastabend@...il.com,
horms@...nel.org, bpf@...r.kernel.org
Subject: Re: [PATCH net-next 01/16] libeth: convert to netmem
On Tue, 27 May 2025 20:49:33 -0700 Mina Almasry wrote:
> > If you don't want to have to validate the low bit during netmem -> page
> > conversions - you need to clearly maintain the separation between
> > the two in the driver. These __netmem_to_page() calls are too much of
> > a liability.
>
> Would it make sense to add a DEBUG_NET_WARN_ON_ONCE to
> __netmem_to_page to catch misuse in a driver independent way? Or is
> that not good enough because there may be latent issues only hit in
> production where the debug is disabled.
Yes, DEBUG_NET_WARN_ON_ONCE() is not ideal. The condition may trigger
pretty rarely, and what are we saving? A single branch per packet on
a HW-GRO capable device?
Isn't the netmem vs page confusion here primarily because we want to
use the same struct to hold head and payload pages?
Powered by blists - more mailing lists