udp 从驱动程序发送
我有一个驱动程序需要：
- 从 FPGA 接收数据
- DMA 数据到另一个设备 (DSP) 进行编码
- 通过 UDP 将编码数据发送到外部主机
最初的计划是让应用程序处理步骤 3，但应用程序并没有这样做在下一组数据从 FPGA 到达之前，处理器无法及时处理数据。
有没有办法强制调度程序（来自驱动程序）运行我的应用程序？
如果没有，我认为工作队列可能是我需要使用的解决方案，但我不确定如何/在哪里调用网络堆栈/驱动程序来完成来自工作队列的 UDP 传输。
有什么想法吗？
I have a driver that needs to:
- receive data from an FPGA
- DMA data to another another device (DSP) for encoding
- send the encoded data via UDP to an external host
The original plan was to have the application handle step 3, but the application doesn't get the processor in time to process the data before the next set of data arrives from the FPGA.
Is there a way to force the scheduler (from the driver) to run my application?
If not, I think work queues are likely the solution I need to use, but I'm not sure how/where to call into the network stack/driver to accomplish the UDP transfers from the work queues.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该尝试找出应用程序“无法足够快地获取数据”的原因。
您的内存带宽可能远远优于典型的以太网带宽，因此即使将数据从驱动程序传递到应用程序也涉及复制。
如果 udp 链接在用户空间中不够快，那么在内核空间中也不会更快。
您需要做的是：
您可以将应用程序分成两个线程，共享缓冲区列表
线程 A 等待驱动程序有可用数据，并将其放在列表的末尾。
线程B从链表头部读取数据，并通过UDP发送。如果由于某种原因线程 B 正忙于等待发送特定缓冲区，则 fifo 会填满一点，但只要 UDP 链路带宽大于来自 DSP 的数据速率，就应该没问题。
将东西移到内核中并不会让事情变得神奇地更快，只是编码、调试和跟踪变得更加困难。
You should try to discover why the application "can't get the data fast enough".
Your memory bandwith is probably vastly superior to the thypical ethernet bandwith, so even if passing data from the driver to the application involves copying.
If the udp link is not fast enough in userspace, it won't be faster in kernelspace.
What you need to do is :
You can probably split your application in two thread, sharing buffer list
thread A waits for the driver to have data available, and puts it at the tail of the list.
thread B reads data from the head of the list, and sends it through UDP. If for some reason thread B is busy waiting for a particular buffer to be sent, the fifo fills a bit, but as long as the UDP link bandwith is larger than the rate of data coming from the DSP you should be fine.
Moving things into the kernel does not makes things magically faster, it is just MUCH harder to code and debug and trace.