[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250715060649.03b3798c@kernel.org>
Date: Tue, 15 Jul 2025 06:06:49 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Dragos Tatulea <dtatulea@...dia.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Andrew Lunn
<andrew+netdev@...n.ch>, Jens Axboe <axboe@...nel.dk>, parav@...dia.com,
Cosmin Ratio <cratiu@...dia.com>, Tariq Toukan <tariqt@...dia.com>, Pavel
Begunkov <asml.silence@...il.com>, Mina Almasry <almasrymina@...gle.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
io-uring@...r.kernel.org
Subject: Re: [PATCH v2 net-next] net: Allow SF devices to be used for ZC DMA
On Mon, 14 Jul 2025 21:39:30 -0700 Christoph Hellwig wrote:
> > LGTM, but we need a better place for this function. netdevice.h is
> > included directly by 1.5k files, and indirectly by probably another 5k.
> > It's not a great place to put random helpers with 2 callers.
> > Maybe net/netdev_rx_queue.h and net/core/netdev_rx_queue.c?
> > I don't think it needs to be a static inline either.
>
> The whole concept is also buggy. Trying to get a dma-able device by
> walking down from an upper level construct like the netdevice can't work
> reliably. You'll need to explicitly provide the dma_device using either
> a method or a pointer to it instead of this guesswork.
Yeah, I'm pretty sure we'll end up with a method in queue ops.
But it's not that deep, an easy thing to change.
Powered by blists - more mailing lists