Linux内核中sk_buff结构详解

Linux内核中sk_buff结构详解,第1张

sk_buff是Linux网络中最核心的结构体,它用来管理和控制接收或发送数据包的信息。各层协议都依赖于sk_buff而存在。内核中sk_buff结构体在各层协议之间传输不是用拷贝sk_buff结构体,而是通过增加协议头和移动指针来 *** 作的。如果是从L4传输到L2,则是通过往sk_buff结构体中增加该层协议头来 *** 作;如果是从L4到L2,则是通过移动sk_buff结构体中的data指针来实现,不会删除各层协议头。这样做是为了提高CPU的工作效率。

skb_buff结构如下所示:

这里要声明两个概念的区别,后续直接用这两个概念,注意区分:

(1)线性数据:head - end。

(2)实际线性数据:data - tail,不包含线性数据中的头空间和尾空间。

skb->data_len : skb中的分片数据(非线性数据)的长度。

skb->len : skb中的数据块的总长度,数据块包括实际线性数据和非线性数据,非线性数据为data_len,所以skb->len= (data - tail) + data_len。

skb->truesize : skb的总长度,包括sk_buff结构和数据部分,skb=sk_buff控制信息 + 线性数据(包括头空间和尾空间) + skb_shared_info控制信息 + 非线性数据,所以skb->truesize = sizeof(struct sk_buff) + (head - end) + sizeof(struct skb_shared_info) + data_len。

sk_buff结构体中的都是sk_buff的控制信息,是网络数据包的一些配置,真正储存数据的是sk_buff结构体中几个指针指向的数据区中,线性数据区的大小 = (skb->end - skb->head),对于每个数据包来说这个大小都是固定不变的,在传输过程中skb->end和skb->head所指向的地址都是不变的,这里要注意这个地址不是本机的地址,如果是本机的地址那么数据包传到其他主机上这个地址就是无效的,所以这个地址是这个skb缓冲区的相对地址。

线性数据区是用来存放各层协议头部和应用层发下来的数据。各层协议头部相关信息放在线性数据区中。实际数据指针为data和tail,data指向实际数据开始的地方,tail指向实际数据结束的地方。

用一张图来表示sk_buff和数据区的关系:

这一节介绍先行数据区在sk_buff创建过程中的变化,图中暂时省略了非线性数据区:

2.1中所讲的都是线性数据区中的相关的配置,当线性数据区不够用的时候就会启用非线性数据区作为数据区域的扩展,skb中用skb_shared_info分片结构体来配置非线性数据。

skb_shared_info结构体是和skb中的线性数据区一体的,所以在skb的各种 *** 作时都会把这两个结构看作是一个结构来 *** 作。如:

skb_shared_info结构:

非线性数据区有两种不同的构成数据的方式

(1)用数组存储的分片数据区,采用是是结构体中的frags[MAX_SKB_FRAGS]

对于frags[]一般用在当数据比较多,在线性数据区装不下的时候,skb_frag_t中是一页一页的数据,skb_frag_struct结构体如下:

下图显示了frags是怎么分配分片数据的:

(2)frag_list指针来指向的分片数据:

参考:

查看系统内存的使用状态

监控报警可用内存空间不足,常规的解决方案如下:

本文将介绍定期清除页面缓存,但是过会儿内存又被占满问题的分析。

查看更详细的内存信息:

$ cat /proc/meminfo |grep -E "Buffer|Cache|Swap|Mem|Shmem|Slab|SReclaimable|SUnreclaim"

清除缓存策略:

1:清除page cache

2:清除slab分配器中的对象(包括目录项和inode)

3:清除page cache和slab分配器中的对象

OOM killer及Overcommit

Linux buffer/cache 内存占用过高的原因以及解决办法

Linux查看Buffer&Cache被哪些进程占用

两者都是RAM中的数据。简单来说,buffer是即将要被写入磁盘的,而cache是被从磁盘中读出来的。 缓存(cached)是把读取过的数据保存起来,重新读取时若命中(找到需要的数据)就不要去读硬盘了,若没有命中就读硬盘。


欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/yw/7154374.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-02
下一篇2023-04-02

发表评论

登录后才能评论

评论列表(0条)

    保存