虚拟化篇之前后端驱动分析-阿里云开发者社区

开发者社区> 阿里云支持与服务> 正文

虚拟化篇之前后端驱动分析

简介: 前后端驱动是虚拟化的重要组成部分,在我们平时的排查过程中,经常会涉及到这部分的数据,特别是与性能相关的问题类型。举个例子,我们经常会碰到网络抖动的问题,此时我们会在实例内部和后端vif口抓包,如果发现两者之间存在延迟,经常我们就会怀疑到前后端的问题。

前后端驱动是虚拟化的重要组成部分,在我们平时的排查过程中,经常会涉及到这部分的数据,特别是与性能相关的问题类型。举个例子,我们经常会碰到网络抖动的问题,此时我们会在实例内部和后端vif口抓包,如果发现两者之间存在延迟,经常我们就会怀疑到前后端的问题。因此我们需要对其工作原理和排查方法需要有一个全面的了解,其中也涉及到一些调试技巧,如为了确定问题是否与前后端队列有关,需要在实例系统的core dump内解析出内存中的队列数据。

何为前后端:

说到前后端就要提到virtIO,virtIO是IBM提出的实现虚拟机内部和宿主机之前数据交换的一种方式,与之前所谓全虚拟化方式比较即通过qemu在模拟设备的方式,性能有了较大的提升。我们在本文中仅局限于网卡设备,这也是因为在实例案例中网络部分占了主导地位。简单来讲,在virtIO体系中分为前端驱动和后端驱动两个部分,前端驱动我们一般可以理解为虚拟机内部的虚拟网卡的驱动,当然Windows和Linux的驱动是不同的,后端驱动virtIO是宿主机上的部分 的实现可能会有不同的方式,我们常见的是vhost-net,内核模式的vhost,至于其他模式如用户态vhost、qemu等等又有不同,但是本质的功能是类似的,就是将前端驱动发出的报文转发到NC虚拟交换机上,同理将收到的报文传入实例内的前端驱动。

vhost01.JPG

上面这张图表示了前面驱动和后端驱动的关系。简单来讲前端驱动就是虚拟机内的虚拟网卡驱动,而后端驱动是主机上的vhost进程负责将报文转发出来,或者将物理机上接受到的报文转发进虚拟机。这两者其实就是负责了虚拟机内外的数据交换。

前后端之间如何交换数据

总的来说两者是通过vring、或者说virt queue即前后端环形队列进行数据交换。一共存在三个队列:

crash> struct vring
struct vring {
unsigned int num;
struct vring_desc *desc;
struct vring_avail *avail;
struct vring_used *used;
}

  1. desc队列 - 放置了所有真正的报文数据。
  2. avail队列与used队列 - 在发送报文的时候,前端驱动将报文在desc中的索引放在avail队列中,后端驱动从这个队列里获取报文进行转发,处理完之后将这些报文放入used队列。在接受报文的时候前端驱动将空白的内存块放入avail队列中(当然也只是报文在desc队列中的索引而已),后端接受报文将内容填充后,将这些含数据的报文放入used队列。

这三个队列都是固定长度的环形队列,当然实现仅仅是对相应索引号对最大长度去余而已。下面这张图形象地表明三个队列和前后端驱动的关系:

vhost02.JPG

主要的数据结构

我们以前端的发送队列为例,注意所有的结构信息都是在虚拟机内部可见的,可以通过core dump查看:

struct vring_virtqueue {
vq = {
list = {
next = 0xffff881027e3d800,
prev = 0xffff881026d9b000
},
callback = 0xffffffffa0149450,
name = 0xffff881027e3ee88 "output.0", ->>表明是发送队列
vdev = 0xffff881023776800,
priv = 0xffff8810237d03c0
},
vring = {
num = 256, ->>所有的队列长度
desc = 0xffff881026d9c000, ->> desc队列
avail = 0xffff881026d9d000, ->> avail队列
used = 0xffff881026d9e000 ->> used队列
},
broken = false,
indirect = true,
event = true,
num_free = 0, ->> 队列目前有多少空闲元素了,如果已经为0表明队列已经阻塞,前端将无法发送报文给后端
free_head = 0, ->> 指向下一个空闲的desc元素
num_added = 0, ->>是最近一次操作向队列中添加报文的数量
last_used_idx = 52143, 这是前端记录他看到最新的被后端用过的索引(idx),是前端已经处理到的used队列的idx。前端会把这个值写到avail队列的最后一个元素,这样后端就可以得知前端已经处理到used队列的哪一个元素了。

<> ->> last_avail_idx 前端不会碰,而且前端的virtqueue结构里就没有这个值,这个代表后端已经处理到avail队列的哪个元素了,前端靠这个信息来做限速,后端是把这个值写在used队列的最后一个元素,这样前端就可以读到了。

notify = 0xffffffffa005a350,
queue_index = 1,
data = 0xffff881026d9f078
}

crash> struct vring_avail 0xffff881026d9d000
struct vring_avail {
flags = 0,
idx = 52399, ->> avail队列的下个可用元素的索引
ring = 0xffff881026d9d004 ->> 队列数组
}

crash> struct vring_used
struct vring_used {
__u16 flags;
__u16 idx; ->> used队列的下个可用元素的索引
struct vring_used_elem ring[]; ->> 队列数组
}

报文发送的具体流程

相比接受,报文发送是我们处理案例中主要遇到问题的部分,所以我们将其流程单独拿出来详细分析一下。

主要以前端驱动(Linux版本)的行为为主,后端行为设计到阿里云源码实现暂不做分析,但是从前端行为基本可以判断后端的大致行为:

  1. 保存head = vq->free_head。

  2. 首先为报文分配desc,即报文的描述块,包含映射到内存的报文内容。

  3. 判断队列的num_free是否小于要发送desc元素个数,如果是的话,说明队列已经阻塞了,后端驱动无法及时处理,所以此时需要通知(notify)后端驱动,前端通知后端的方法就是写入notification register寄存器。

  4. 调整num_free减去已经分配的desc元素数量。

  5. 调整free_head指向下一个空闲的desc元素。

  6. 计算本次应该用avail ring中的哪个元素(即得出元素索引),avail队列是个环形数组,这里通过(vq->vring.avail->idx) & (vq->vring.num - 1)达到取余的目的。

  7. 记录本次逻辑buf的起始desc索引号,即将根据刚才得出的元素索引找到相应在avail中的元素,将该元素的值指向本次分配desc的元素。这样处理之后avail队列中就已经包含了要处理的报文了(当然只是指向desc的索引而已)

  8. 调整avail->idx指向了下一次操作使用avail队列的哪个元素。

  9. 调整num_added记录增加了几个可用的avail ring元素。

  10. 根据skb->xmit_more的值来决定是否"kick"即通知(notify)后端驱动。xmit_more值代表是否后续还有更多的报文需要发送,如果没有,前端驱动就会决定kick,如果有前端驱动会继续等待其他报文进入队列后再一起"kick"。

  11. 在决定是否要notify后端驱动时,这里有一个限速逻辑:

    1. 首先提取used队列中最后一个元素,这是后端填入的信息,表示后端驱动处理到哪个avail队列的元素了,将值保存到event_idx。
    2. 记录上一次avail队列idx索引的值到old。
    3. 记录这一次报文进入队列之后avail队列idx索引的值到new_idx。
    4. 于是这里有一个公式来最后决定是否要notify后端驱动,即所谓的限速逻辑:

      (new_idx - event_idx - 1) < (new_idx - old)

用一张图来表示这个限速逻辑:

第一种情况,当前后端处理速度很快,前端应当notify后端驱动:

vhost03.JPG

第二种情况,后端处理速度跟不上前端发送报文速度,暂时不要notify后端:

vhost04.JPG

前端队列的状态分析

这里介绍的主要是通过core dump分析前端队列的方法,后端由于涉及到线上物理机,我们往往无法进行有效的分析。

Linux Core Dump

由于后端缺乏详尽的日志,我们往往需要依赖前端进行分析,而前后端队列的状态是在内核态,因此core dump是成了比较重要的分析手段了。以下介绍怎样通过Linux Core Dump对前后端队列进行分析:

首先通过net命令可以直接获取所有net_device的地址:

crash> net
NET_DEVICE NAME IP ADDRESS(ES)
ffff881028c66020 lo 127.0.0.1
ffff8810225f5020 eth0 172.20.1.13

获取其中的device地址:

crash> struct net_device ffff8810225f5020 -o | grep device
struct net_device {
[ffff8810225f50a0] struct net_device_stats stats;
[ffff8810225f5168] const struct net_device_ops *netdev_ops;
[ffff8810225f5198] struct net_device *master;
[ffff8810225f5408] struct net_device *link_watch_next;
[ffff8810225f5418] void (*destructor)(struct net_device *);
[ffff8810225f5450] struct device dev; --->> device地址

获取其中的parent指针:

crash> struct device ffff8810225f5450 | grep parent
parent = 0xffff881023776810,

将结果减去10就是virtio_device结构:

crash> struct virtio_device ffff881023776800 -o
struct virtio_device {
[ffff881023776800] int index;
[ffff881023776804] bool config_enabled;
[ffff881023776805] bool config_change_pending;
[ffff881023776808] spinlock_t config_lock;
[ffff881023776810] struct device dev;
[ffff881023776a30] struct virtio_device_id id;
[ffff881023776a38] struct virtio_config_ops *config;
[ffff881023776a40] struct list_head vqs; ----->> 所有队列的地址
[ffff881023776a50] unsigned long features[1];
[ffff881023776a58] void *priv;

列出所有队列的地址:

crash> list ffff881023776a40
ffff881023776a40
ffff881026d9b000 ->> input.0 接受队列
ffff881026d9f000 ->> output.0 发送队列
ffff881027e3d800 ->> control控制指令队列

我们一般比较多关注发送队列,因此挑选发送队列来看:

crash> struct vring_virtqueue ffff881026d9f000
struct vring_virtqueue {
vq = {
list = {
next = 0xffff881027e3d800,
prev = 0xffff881026d9b000
},
callback = 0xffffffffa0149450,
name = 0xffff881027e3ee88 "output.0",
vdev = 0xffff881023776800,
priv = 0xffff8810237d03c0
},
vring = {
num = 256,
desc = 0xffff881026d9c000,
avail = 0xffff881026d9d000,
used = 0xffff881026d9e000
},
broken = false,
indirect = true,
event = true,
num_free = 0, ----->> 表明队列已满
free_head = 0,
num_added = 0,
last_used_idx = 52143,
notify = 0xffffffffa005a350,
queue_index = 1,
data = 0xffff881026d9f078
}

当然还可以打出desc、avail和used每个数组的情况。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

分享阿里云支持与服务团队最佳实践、经典案例与故障排查。

官方博客
文档