Re: [PATCH net-next] xsk: introduce xsk_dma_ops

[Christoph Hellwig <hch@infradead.org>]

On Mon, Apr 17, 2023 at 11:19:47PM -0700, Jakub Kicinski wrote:
> > You can't just do dma mapping outside the driver, because there are
> > drivers that do not require DMA mapping at all.  virtio is an example,
> > but all the classic s390 drivers and some other odd virtualization
> > ones are others.
> 
> What bus are the classic s390 on (in terms of the device model)?

I think most of them are based on struct ccw_device, but I'll let the
s390 maintainers fill in.

Another interesting case that isn't really relevant for your networking
guys, but that caused as problems is RDMA.  For hardware RDMA devices
it wants the ULPs to DMA map, but it turns out we have various software
drivers that map to network drivers that do their own DMA mapping
at a much lower layer and after potentially splitting packets or
even mangling them.

> 
> > > I don't think it's reasonable to be bubbling up custom per-subsystem
> > > DMA ops into all of them for the sake of virtio.  
> > 
> > dma addresses and thus dma mappings are completely driver specific.
> > Upper layers have no business looking at them.
> 
> Damn, that's unfortunate. Thinking aloud -- that means that if we want 
> to continue to pull memory management out of networking drivers to
> improve it for all, cross-optimize with the rest of the stack and
> allow various upcoming forms of zero copy -- then we need to add an
> equivalent of dma_ops and DMA API locally in networking?

Can you explain what the actual use case is?

From the original patchset I suspect it is dma mapping something very
long term and then maybe doing syncs on it as needed?