避免在用户空间和内核空间之间复制数据,反之亦然

发布于 2024-08-31 07:56:42 字数 269 浏览 3 评论 0原文

我正在开发一种用于并行计算的主动消息传递协议,以取代 TCP/IP。我的目标是减少数据包的延迟。由于环境是局域网,我可以用更简单的协议替换TCP/IP,以减少数据包延迟。我没有编写任何设备驱动程序,我只是尝试用更简单的东西替换 TCP/IP 堆栈。现在我想避免将数据包的数据从用户空间复制到内核空间,反之亦然。我听说过 mmap()。这是最好的方法吗?如果是,如果您能提供一些示例的链接,那就太好了。我是一个linux新手,我真的很感谢你的帮助..谢谢你...

谢谢, 巴拉

I am developing a active messaging protocol for parallel computation that replaces TCP/IP. My goal is to decrease the latency of a packet. Since the environment is a LAN, i can replace TCP/IP with simpler protocol to reduce the packet latency. I am not writing any device driver and i am just trying to replace the TCP/IP stack with something simpler. Now I wanted to avoid copying of a packet's data from user space to kernel space and vice-versa. I heard of the mmap(). Is it the best way to do this? If yes, it will be nice if you can give links to some examples. I am a linux newbie and i really appreciate your help.. Thank you...

Thanks,
Bala

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浅听莫相离 2024-09-07 07:56:42

你应该使用UDP,那已经相当快了。至少它的速度足以让 W32/SQLSlammer 在整个互联网上传播。

关于您最初的问题,请参阅 (vm)splicetee Linux 系统调用。

从联机帮助页:

三个系统调用splice(2),
vmsplice(2) 和 tee(2)),提供
具有完全控制权的用户空间程序
在任意内核缓冲区上,
使用在内核中实现
使用的缓冲区类型相同
对于一个管道。总而言之,这些系统
调用执行以下任务:

拼接(2)

 将数据从缓冲区移动到任意文件描述符,反之亦然

反之亦然,或者从一个缓冲区到另一个缓冲区。

三通(2)

 将数据从一个缓冲区“复制”到另一个缓冲区。

vmsplice(2)

 将数据从用户空间“复制”到缓冲区中。

虽然我们谈论的是复制,但实际上
通常避免复印。这
内核通过实现一个
管道缓冲区作为一组
指向页面的引用计数指针
内核内存。内核创建
缓冲区中页面的“副本”
创建新指针(用于输出
buffer)引用页面,以及
增加引用计数
页:仅复制指针,
不是缓冲区的页面。

You should use UDP, that is already pretty fast. At least it was fast enough for W32/SQLSlammer to spread through the whole internet.

About your initial question, see the (vm)splice and tee Linux system calls.

From the manpage:

The three system calls splice(2),
vmsplice(2), and tee(2)), provide
userspace programs with full control
over an arbitrary kernel buffer,
implemented within the kernel using
the same type of buffer that is used
for a pipe. In overview, these system
calls perform the following tasks:

splice(2)

  moves data from the buffer to an arbitrary file descriptor, or vice

versa, or from one buffer to another.

tee(2)

  "copies" the data from one buffer to another.

vmsplice(2)

  "copies" data from user space into the buffer.

Though we talk of copying, actual
copies are generally avoided. The
kernel does this by implementing a
pipe buffer as a set of
reference-counted pointers to pages of
kernel memory. The kernel creates
"copies" of pages in a buffer by
creating new pointers (for the output
buffer) referring to the pages, and
increasing the reference counts for
the pages: only pointers are copied,
not the pages of the buffer.

星星的轨迹 2024-09-07 07:56:42

由于环境是局域网,我可以用更简单的协议替换 TCP/IP 以减少数据包延迟

一般情况下,即使在局域网中 UDP 数据包也容易丢失,如果客户端也会丢失
没有足够的时间来消耗它......

所以不,不要用其他东西(UDP)替换TCP。因为如果您确实需要可靠的传输,TCP 将是最快的(因为连接到确认和重传的所有内容都是在内核空间中完成的)。

一般来说,在正常情况下,使用 TCP 没有延迟缺点(当然不要忘记 TCP_NODELAY 选项)

关于共享内存。实际上,您分配的所有内存都是通过 mmap 创建的。因此,当内核从驱动程序创建数据包时,无论如何都需要以某种方式复制它。

如果您正在谈论减少复制,通常是针对文件/套接字完成的,
使用 sendfile() 确实可以防止在内核和用户之间复制数据。但我假设
您不需要发送文件。

Since the environment is a LAN, i can replace TCP/IP with simpler protocol to reduce the packet latency

Generally, even in LAN UDP packets tend to be lost, also they will be lost if client
do not have enough time to consume it...

SO no, do not replace TCP with something else (UDP). Because if you do need reliable delivery TCP would be the fastest (because everything connected to acknowledgments and retransmission is done in kernel space).

Generally in normal case there is no latency drawbacks using TCP (of course do not forget TCP_NODELAY option)

About sharing the memory. Actually all memory you allocate is created with mmap. So the kernel will need to copy it somehow in any case when it creates a packet from driver.

If you are talking about reducing copying it is usually done for files/sockets and
sendfile() used that indeed prevents copying data between kernel and user. But I assume
you do not need to send files.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文