dpdk中文-mbuf的基本操作

来源:互联网 发布:在线音乐识别软件 编辑:程序博客网 时间:2024/05/22 00:35
mbuf是报文中的描素的结构体,是整个转发过程中最核心的数据结构之一。主要针对于mbuf的常用API与基本原理做一个简单的介绍:
首先我们看一下rte_mbuf的数据结构的定义:先主要说明几个跟数据有关的变量
struct rte_mbuf {
。。。。
void *buf_addr; /**< Virtual address of segment buffer. */
。。。。
uint16_t data_off;
。。。。
uint32_t pkt_len; /**< Total pkt len: sum of all segments. */
uint16_t data_len; /**< Amount of data in segment buffer. */
uint16_t buf_len
。。。
}
既然叫mbuf,其实就是一种buf管理的结构体:

如上图所示:
mbuf整个用来存数据的buf就是上图所示的内容。
一般数据都会有分3个区域;
1。headroom
2。data
3。tailroom
其实这个中间还包含一个含义,整个buf的大小。 也就是数据结构中的buf_len的大小一般是4096
其中headroom一般含义是:
保留区域headroom:一般用来存放用户自己针对于mbuf的一些描素信息,一般保留给用户使用,可以通过修改mbuf头文件,来实现headroom的大小;data_off的默认值就是mbuf的headroom的大小;默认就是128。如果要定义超过这个范围的私有字段,请自行修改 RTE_PKTMBUF_HEADROOM

数据字段:data。data区域一般指的是地址区间在data_off+buf_addr 到data_off+data_len+buf_add即,data_len就是这段数据的长短,这个data_len一般都是通过mbuf的几个基本操作,或者通过赋值来实现的。
tailroom:一般指的是,data_len还未包含的东西。默认其实data_len是0。所以说默认来说tailroom应该是占了很大的空间的;
其实mbuf的控制,就是不断的控制这个几个区域的大小,永远记住,我们的报文数据永远是存放在data中的;主要控制的就是data_off 与data_len
至于pkt_len在普通情况下,就是核data_len是一个大小,在大报文的时候,就是两个mbuf通过链表组合起来的~
mbuf几个基本操作以及注意点:

rte_pktmbuf_prepend
移动data_off指针,注意:需要查看返回值,如果已经偏移到headroom的时候,会返回NULL;(报文向前扩容),例如报文从应用层往下,一层一层的封装就用这个。
rte_pktmbuf_append
改变data_len的长度 ,返回改变前的尾地址。(向后扩容)
例如先有首部再填数据字段,就可以用这个
rte_pktmbuf_adj
(首部向后缩小空间) 改变data_off的值 从二层到三层转发,去二层头就可以用这个
rte_pktmbuf_trim
(尾部向前缩小空间) 移动data_len减少buf_len;(预分配的内容太大,数据没那么大可以用这个)
总结:
这4个API就是我们常见的调整数据部分大小,其实用法和API的名字和内核的skbuf类似。

rte_pktmbuf_mtod
rte_pktmbuf_mtod_offset
这两个API就是就是返回buf_addr+data_off +useroff 然后再强制类型转换一下而已~~
只是mtod这个API默认是useroff ==0而已。就是把数据data部分的首指针返回。
注意:
这个API其实是不安全的,往这个地址里面copy内容的时候,注意数据的长度~。。
有用的连接:
http://www.cnblogs.com/ziding/p/4214499.html
http://blog.csdn.net/todd911/article/details/24182551
其实mbuf不仅仅可以用来装报文~~只要是数据缓存都可以~~~~



1 0