Displaying 3 results from an estimated 3 matches for "xsk_dma_op".
Did you mean:
xsk_dma_ops
2023 Apr 25
1
[PATCH net-next] xsk: introduce xsk_dma_ops
On Thu, Apr 20, 2023 at 09:18:21AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 20, 2023 at 05:11:48PM +0800, Xuan Zhuo wrote:
> > I know that the current design of DMA API only supports some physical hardware,
> > but can it be modified or expanded?
>
> I think the important point is that for some cases there is no need
> to dma map at all, and upper layers should be
2023 May 01
0
[PATCH net-next] xsk: introduce xsk_dma_ops
On Thu, Apr 20, 2023 at 06:42:17PM +0200, Alexander Lobakin wrote:
> When there's no recycling of pages, then yes. And since recycling is
> done asynchronously, sometimes new allocations happen either way.
> Anyways, that was roughly a couple years ago right when you introduced
> dma_alloc_noncoherent(). Things might've been changed since then.
> I could try again while next
2023 Apr 20
1
[PATCH net-next] xsk: introduce xsk_dma_ops
On Wed, Apr 19, 2023 at 09:45:06AM -0700, Jakub Kicinski wrote:
> > 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?
>
> In this case yes, pinned user memory, it gets sliced up into MTU sized
> chunks, fed into an Rx queue of a