Thread (23 messages) 23 messages, 5 authors, 2025-07-11

Re: [RFC net-next 1/4] net: Allow non parent devices to be used for ZC DMA

From: Dragos Tatulea <dtatulea@nvidia.com>
Date: 2025-07-08 14:27:29
Also in: lkml

On Tue, Jul 08, 2025 at 12:08:48PM +0100, Pavel Begunkov wrote:
On 7/4/25 14:11, Dragos Tatulea wrote:
quoted
On Thu, Jul 03, 2025 at 01:58:50PM +0200, Parav Pandit wrote:
quoted
quoted
From: Jakub Kicinski <kuba@kernel.org>
Sent: 03 July 2025 02:23 AM
...>> In an offline discussion, Dragos mentioned that io_uring already
quoted
quoted
operates at the queue level, may be some ideas can be picked up
from io_uring?
The problem for devmem is that the device based API is already set in
stone so not sure how we can change this. Maybe Mina can chime in.

To sum the conversation up, there are 2 imperfect and overlapping
solutions:

1) For the common case of having a single PCI device per netdev, going one
    parent up if the parent device is not DMA capable would be a good
    starting point.

2) For multi-PF netdev [0], a per-queue get_dma_dev() op would be ideal
    as it provides the right PF device for the given queue. io_uring
    could use this but devmem can't. Devmem could use 1. but the
    driver has to detect and block the multi PF case.

I think we need both. Either that or a netdev op with an optional queue
parameter. Any thoughts?
No objection from zcrx for either approach, but it sounds like a good
idea to have something simple for 1) sooner than later, and perhaps
marked as a fix.
Sounds good. This is light enough to be a single patch.

Will tackle multi-PF netdev in a subsequent series.

Thanks,
Dragos
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help