Chinaunix

标题: 关于ip_append_data函数的问题 [打印本页]

作者: jiufei19 时间: 2010-11-29 10:48
标题: 关于ip_append_data函数的问题
大家好，在阅读《understanding linux network internals 》一书中第21章时，遇到如下描述：

If the L4 layer wants fast response time, it might call ip_push_pending_frames after each call to ip_append_data. But the two functions are provided so that the L4 layer can buffer as much data as possible (up to the size of the PMTU) and then send it at once to be efficient.

现在我有点不解的问题是，该文中所说的“ If the L4 layer wants fast response time” 是什么意思？换句话讲，L4层什么时候认为需要快速响应，什么时候又不需要呢？决定权在哪里？

作者: Godbach 时间: 2010-11-29 10:51
我记得 socket 有个选项是 NODELAY，应该是告诉传输层尽快发送数据，就是不需要等待数据达到 PMTU 的时候，才发送

作者: jiufei19 时间: 2010-11-29 11:03
回复 2# Godbach

谢谢斑竹！

斑竹说的是TCP_NODELAY 这个选项吗？查了下资料，该选项的用法如下：

If set, this option disables TCP's Nagle algorithm (Section 19.4 of TCPv1 and pp. 858–859 of TCPv2). By default, this algorithm is enabled

显然，对于ip_build_and_send_pkt和ip_send_reply这两个函数而言，正好符合这个要求，因为这两个函数是TCP用于发送SYN ACKs、RST分段的，因此这两个函数都不会和应用层数据有关。那么是否能这样理解，如果L4数据是来自应用层的数据，那么是不会有所谓L4调用ip_append_data函数缓存该应用层待发送数据的现象？

作者: Godbach 时间: 2010-11-29 11:06
ip_append_data 实际上主要的任务就是处理应用层的数据，并将其缓存，但是不负责数据的发送。数据的发送由 ip_push_pending_frames 负责

作者: Godbach 时间: 2010-11-29 11:10
ip_append_data 这个函数 LZ 理解的怎么样了。可以交流一下，我最近也在看这些东西

作者: jiufei19 时间: 2010-11-29 11:14
回复 4# Godbach

谢谢！

我感觉我的表述没有清楚，我想表达的意思好像不是我的本意，晕了，我再整理下思路后，再来请教。

作者: Godbach 时间: 2010-11-29 11:28

If the L4 layer wants fast response time, it might call ip_push_pending_frames after each call to ip_append_data

其实建议接着在后面看一些内核你就明白了。
传输层发送数据，涉及到高效率和高响应率。ip_push_pending_frames 这个函数被调用之前，可能有到多次调用 ip_append_data。

如果你想要高响应率，那么就调用一次 ip_append_data 之后，尽快执行 ip_push_pending_frames 。
如果你想高效率，一次尽可能多的发数据，那就可以多次调用 ip_append_data，知道缓冲的数据达到 PMTU，才调用 ip_push_pending_frames。这样一次发送的数据量比较大。

作者: jiufei19 时间: 2010-11-29 11:31
本帖最后由 jiufei19 于 2010-11-29 11:33 编辑

回复 7# Godbach

谢谢斑竹的热情！

ip_append_data和ip_push_pending_frames这两个函数我已经全部阅读完了，基本上其内部的原理有一个大概的了解。我今天的疑问是发生在回头阅读原书的这几段话时，突然发现自己没有很好理解ip_append_data函数的应用场景了，尤其是对其缓存发送数据的应用场景的全面了解上。

我整理好思路后，再和斑竹交流！

-----------------------------
如果你想要高响应率，那么就调用一次 ip_append_data 之后，尽快执行 ip_push_pending_frames 。
如果你想高效率，一次尽可能多的发数据，那就可以多次调用 ip_append_data，知道缓冲的数据达到 PMTU，才调用 ip_push_pending_frames。这样一次发送的数据量比较大。
----------------------------
这段话的意思我是理解的，我现在的疑问不是指这段话所描述的本身原理，而是------我现在还不知道咋个清晰描述我的问题，呵呵！

作者: Godbach 时间: 2010-11-29 11:32
好的，整理好了发上来一起交流一下。我这块也有不少疑问。疑义相与析啊。:wink:

作者: jiufei19 时间: 2010-11-29 11:41
回复 9# Godbach

斑竹，因为好像问题有点复杂，我先将问题分解下，逐个进行表述，看看能否理清问题思路。

1、首先我想知道的是，ip_append_data被L4层协议调用时，假定L4层协议是UDP协议，那么是否有什么机制进行这里所谓的缓存数据的发送？如果有这个机制是什么？应用层能控制吗？

作者: Godbach 时间: 2010-11-29 11:45
udp_sendmsg 调用这个函数

作者: Godbach 时间: 2010-11-29 11:51
另外，在 udp_sendmsg 中，调用的 ip_append_data 中，是要判断 MSG_MORE 标志位的，这个标志位代表着应用空间很快就用更多的数据下来了，这样分配缓存的时候就会考虑分配一个比较大的

作者: Godbach 时间: 2010-11-29 12:00
看一下 sendmsg 调用的入口参数

ssize_t sendmsg(int s, const struct msghdr *msg, int flags);

最后一个参数 flags 的解释中谈到了 MSG_MORE

   MSG_MORE (Since Linux 2.4.4)
            The caller has more data to send.  This flag is used with TCP sockets to obtain the same effect as the TCP_CORK socket option (see tcp(7)),  with
            the difference that this flag can be set on a per-call basis.

            Since  Linux 2.6, this flag is also supported for UDP sockets, and informs the kernel to package all of the data sent in calls with this flag set
            into a single datagram which is only transmitted when a call is performed that does not specify this flag.  (See also the UDP_CORK socket  option
            described in udp(7).)

作者: jiufei19 时间: 2010-11-29 13:21
回复 13# Godbach

恩，我也man了下sendmsg的说明，的确有此解释。那么第1个问题基本解决，接下来我再继续整理

作者: jiufei19 时间: 2010-11-29 13:59
我在继续复习ip_append_data函数的时候，又突然发现了一个题外问题，即understanding linux network internals一书的图21-3和图21-4所描绘的场景是否有错误？这两个图中第1个skb对应的数据都是PMTU大小，但是PMTU不一定是8的整数倍呀？我有点晕了，以前阅读该章时咋个没有发现此问题呢？

作者: Godbach 时间: 2010-11-29 14:09

这两个图中第1个skb对应的数据都是PMTU大小，但是PMTU不一定是8的整数倍呀？

你的意思填充一个 skb 的时候应该按照 8 字节的边界对齐，是吧，它这里没有显示出来？

作者: Godbach 时间: 2010-11-29 14:20
这个函数的分析篇幅比较大，你在往后看一下，图 21-10，谈到了这个问题

作者: jiufei19 时间: 2010-11-30 14:08
本帖最后由 jiufei19 于 2010-11-30 14:11 编辑

回复 17# Godbach

谢谢斑竹！

我的意思是我说的那几幅图似乎没有符合8字节整数倍的描述，是作者疏忽，还是我理解有误？

it would be better to have every fragment except the last one fill up to the size of the PMTU
这是该书的一段原话，这里提到了除了最后一个分段外其他全部都填充到PMTU大小，显然有点问题？

作者: Godbach 时间: 2010-11-30 14:29
你这个问题，我回帖中提到了，你看一下。

作者: Godbach 时间: 2010-11-30 14:29
第 17 楼的回帖。

作者: jiufei19 时间: 2010-11-30 15:04
回复 20# Godbach

图21-10中的内容我是能理解的，其实就是说明了只要不是最后一个分段，则必须满足8字节边界。因此这正就是我的问题呀，为啥作者在前面的图中把所有不是最后一个分段都画成了占满了整个PMTU呢？一个PMTU是物理上最大的数据长度了，不一定满足8字节边界呀？

请斑竹解惑。

作者: Godbach 时间: 2010-11-30 17:19
我个人的理解就是这个是细节，再深入讨论 ip_append_data 重要的代码实现时，就不提及这个问题了，后面再去做一下解释

作者: jiufei19 时间: 2010-11-30 21:12
回复 22# Godbach

哦，斑竹的意思就是，作者在没有具体阐述ip_append_data函数的处理逻辑前，笼统的用PMTU来表达如何分配skb的大小来存放L4层的数据，然而实际上由于IP协议的规定，除了最后一个分段外，实际是不能这样看待的。

作者: Godbach 时间: 2010-11-30 21:39

笼统的用PMTU来表达如何分配skb的大小来存放L4层的数据，

你是在说 8 字节边界的问题吧。

作者: jiufei19 时间: 2010-11-30 22:12
回复 24# Godbach

是的呀，我的问题就是作者明明知道有8字节边界问题，为啥还在那几幅图中直接让非最后分段充满PMTU呢？

作者: Godbach 时间: 2010-12-01 10:25
嗯，我的理解就是前面的回贴。这个细节，在讨论更重要的话题时，先忽略了。
纯粹个人的看法。

作者: jiufei19 时间: 2010-12-06 10:50
回复 26# Godbach

感谢斑竹，看来的确可能是作者故意这样写，而暂时不涉及更多的细节

作者: Godbach 时间: 2010-12-06 11:58
可以结合书的后面内容，或者原版的英文看一下，有没有作者漏翻译或者翻译不准确的地方

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)