Open hmaarrfk opened 5 years ago
Right, so first they transfer it all to a kernel buffer, THEN they copy it to a user buffer.
[Sat Feb 16 20:05:20 2019] xdma:complete_cyclic: 0-C2H0-ST, result[0].status = 0x52b40001 length = 0x200.
[Sat Feb 16 20:05:20 2019] xdma:complete_cyclic: 0-C2H0-ST, pkt_length=512 (with EOP)
[Sat Feb 16 20:05:20 2019] xdma:copy_cyclic_to_user: 0-C2H0-ST, pkt_len 512, head 0, user buf idx 0.
[Sat Feb 16 20:05:20 2019] xdma:copy_cyclic_to_user: 0-C2H0-ST sg 0, 0x00000000f3eaca70, copy 256 to user 0.
what a waste of memory bandwidth.
I think there are 2 ways forward:
Increase the size of the circular buffer using alloc_pages
instead of alloc_page
. The problem with this is that it still requires a copy from kernel memory to userland memory. Not ideal.
Second, alloc_pages creates contiguous pages which may be difficult to handle in many applications.
We could try and get the userland pointer to the memory in kernel space. Apparently that is a bad idea and we should use mmap
instead.
https://stackoverflow.com/questions/46181090/how-to-avoid-copy-from-user-and-copy-to-user-in-linux-device-driver
For now, lets start with option 1, and see what happens.
*
* Iterate over the userspace buffer, taking at most 255 * PAGE_SIZE bytes for
* each DMA transfer.
I don't think that it actually overwrites your data, just that it consumed all the traffic from the streaming interface
I guess they are putting it in a temporary buffer and copying it again to the userland buffer? that is silly....