本文共 5614 字，大约阅读时间需要 18 分钟。
前后端驱动是虚拟化的重要组成部分，在我们平时的排查过程中，经常会涉及到这部分的数据，特别是与性能相关的问题类型。举个例子，我们经常会碰到网络抖动的问题，此时我们会在实例内部和后端vif口抓包，如果发现两者之间存在延迟，经常我们就会怀疑到前后端的问题。因此我们需要对其工作原理和排查方法需要有一个全面的了解，其中也涉及到一些调试技巧，如为了确定问题是否与前后端队列有关，需要在实例系统的core dump内解析出内存中的队列数据。
说到前后端就要提到virtIO，virtIO是IBM提出的实现虚拟机内部和宿主机之前数据交换的一种方式，与之前所谓全虚拟化方式比较即通过qemu在模拟设备的方式，性能有了较大的提升。我们在本文中仅局限于网卡设备，这也是因为在实例案例中网络部分占了主导地位。简单来讲，在virtIO体系中分为前端驱动和后端驱动两个部分，前端驱动我们一般可以理解为虚拟机内部的虚拟网卡的驱动，当然Windows和Linux的驱动是不同的，后端驱动virtIO是宿主机上的部分 的实现可能会有不同的方式，我们常见的是vhost-net，内核模式的vhost，至于其他模式如用户态vhost、qemu等等又有不同，但是本质的功能是类似的，就是将前端驱动发出的报文转发到NC虚拟交换机上，同理将收到的报文传入实例内的前端驱动。
上面这张图表示了前面驱动和后端驱动的关系。简单来讲前端驱动就是虚拟机内的虚拟网卡驱动，而后端驱动是主机上的vhost进程负责将报文转发出来，或者将物理机上接受到的报文转发进虚拟机。这两者其实就是负责了虚拟机内外的数据交换。
总的来说两者是通过vring、或者说virt queue即前后端环形队列进行数据交换。一共存在三个队列：
crash> struct vring
struct vring { unsigned int num; struct vring_desc *desc; struct vring_avail *avail; struct vring_used *used; }这三个队列都是固定长度的环形队列，当然实现仅仅是对相应索引号对最大长度去余而已。下面这张图形象地表明三个队列和前后端驱动的关系：
我们以前端的发送队列为例，注意所有的结构信息都是在虚拟机内部可见的，可以通过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版本）的行为为主，后端行为设计到阿里云源码实现暂不做分析，但是从前端行为基本可以判断后端的大致行为：
保存head = vq->free_head。
首先为报文分配desc，即报文的描述块，包含映射到内存的报文内容。
判断队列的num_free是否小于要发送desc元素个数，如果是的话，说明队列已经阻塞了，后端驱动无法及时处理，所以此时需要通知（notify）后端驱动，前端通知后端的方法就是写入notification register寄存器。
调整num_free减去已经分配的desc元素数量。
调整free_head指向下一个空闲的desc元素。
计算本次应该用avail ring中的哪个元素（即得出元素索引），avail队列是个环形数组，这里通过(vq->vring.avail->idx) & (vq->vring.num - 1)达到取余的目的。
记录本次逻辑buf的起始desc索引号，即将根据刚才得出的元素索引找到相应在avail中的元素，将该元素的值指向本次分配desc的元素。这样处理之后avail队列中就已经包含了要处理的报文了（当然只是指向desc的索引而已）
调整avail->idx指向了下一次操作使用avail队列的哪个元素。
调整num_added记录增加了几个可用的avail ring元素。
根据skb->xmit_more的值来决定是否"kick"即通知(notify)后端驱动。xmit_more值代表是否后续还有更多的报文需要发送，如果没有，前端驱动就会决定kick，如果有前端驱动会继续等待其他报文进入队列后再一起"kick"。
在决定是否要notify后端驱动时，这里有一个限速逻辑：
于是这里有一个公式来最后决定是否要notify后端驱动，即所谓的限速逻辑：
(new_idx - event_idx - 1) < (new_idx - old)
用一张图来表示这个限速逻辑：
第一种情况，当前后端处理速度很快，前端应当notify后端驱动：
第二种情况，后端处理速度跟不上前端发送报文速度，暂时不要notify后端：
这里介绍的主要是通过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每个数组的情况。
转载地址：http://istyx.baihongyu.com/