但是，这套方案也有有缺点

▼

在new_device()函数中，我们需要做一下几件事。

static int

new_device(int vid) {

...

/*    首先，我们需要调用rte_vhost_crypto_create()函数，该函数用来初始化Vhost Crypto实例。其中vid为Virtio Device设备号，cryptodev_id为初始化好的DPDKCryptodev设备号，crypto_sess_pool和crypto_sess_priv_pool为用来创建和初始化处理VM加解密任务的session。

在Virtio Crypto标准中，session的信息交换为session_id。而在DPDK Cryptodev中session则为一段具体的数据。因此Vhost Crypto的每一个实例都将维护一个用来映射virtio crypto session_id和DPDK Cryptodev session数据的关系的表，并自动处理VM发送的创建及删除session的请求。用户无需进行任何干预，只需在创建实例时提供Cryptodev ID和sessionmempool即可。

*/

rte_vhost_crypto_create(vid,

cryptodev_id,

crypto_sess_pool,

crypto_sess_priv_pool,

rte_lcore_to_socket_id(lcore_id);

...

/*    然后，我们需要告诉Vhost Crypto是否开启zero copy。开启zero copy可让函数避免在处理virtio cryptodata request时对数据进行拷贝和写回，而仅将request的物理地址进行VM->Host的转换。开启zero copy能大幅提升处理效率。

但该方法有一定的局限：要求HOST系统开启IOMMU，VIOMMU也要开启等，同时不支持Host端使用AESNI-MB PMD，以及不支持该数据内存在物理上不连续。在VM中LKCF对每个设备初始化后会进行可行性检测，其中就包括SCATTER-GATHER LIST的正确性检测。开启zero copy会使VM上的设备驱动无法通过这项检测而导致初始化失败，因此需要HOST端在等待LKCF检测完成之后再开启zero copy.*/

rte_vhost_crypto_set_zero_copy(vid,zero_copy);

...

}

Vhost Crypto用户应用的数据面处理也非常简单。以下代码为worker lcore执行的代码片段。

static int

vhost_crypto_worker(void *arg) {

uint16_tinflight = 0;

intcallfds[MAX_NB_VIRTIO_CRYPTO_DEVICES];

structrte_crypto_op *ops[burst_size];

...

/*  首先分配一个burst的DPDK Crypto Operation */

rte_crypto_op_bulk_alloc(cop_pool,RTE_CRYPTO_OP_TYPE_SYMMETRIC, ops,

burst_size);

/*  实际处理VM Crypto Data Request的无限循环 */

for(;;) {

uint16_tfetched;

//    获得能完整enqueue到Cryptodev中operation数的大小，详见下文 nb_ops =RTE_MIN(burst_size, NB_DESCRIPTORS – inflight */

/*    从virtio queue中获取最大nb_ops个virtio crypto request并转换成DPDK Crypto Operation，并写入ops中，最后返回处理完成的ops数量。*/

fetched = rte_vhost_crypto_fetch_requests(vid,virtio_queue_id,

ops,nb_ops);

/*    将转换好的ops enqueue到Cryptodev的queue中。*/

inflight+= rte_cryptodev_enqueue_burst(cryptodev_id, queue_id,

ops,fetched);

/*    一个小贴士：DPDK Cryptodev的queue并非无限大，倘若该qeueue已经饱和，以上操作将不能成功enqueue到fetched个operation。而未能成功enqueue的operation必须妥善保存，以避免VM的crypto request丢失。因此，建议用户记录下初始Cryptodev Queue时指定NB_DESCRIPTORS（即为Queue的大小）。在调用rte_vhost_crypto_fetch_requests（）时用其与inflight比较来获得合适的nb_ops大小，以避免fetched太多而不能enqueue的情况发生。记录inflight也可以用来进行更复杂的SLA相关操作，如QoS等 */

/*    将DPDK Cryptodev处理完的Crypto Operation Dequeue出来 */

fetched= rte_cryptodev_dequeue_burst(cryptodev_id, queue_id,

ops_dequeue, RTE_MIN(burst_size, inflight));

/*    更新inflight */

inflight-= fetched;

/*    因为Cryptodev操作的异步性，dequeue的operation未必为刚刚enqueue的，而且也不一定属于同一个Virtio Device。因此要调用以下函数将处理好的buffer写回（zero copy未开启）,并在callfds中记录该burst中所有request的所有Virtio Device ID */

rte_vhost_crypto_finalize_requests(ops_dequeue,

fetched,callfds, &nb_callfds);

/*  最后，通知每一个Virtio Device，加解密工作完成 */

for(i = 0; i < nb_callfds; i++)

eventfd_write(callfds[i],(eventfd_t)1);

}

Vhost Crypto的API具有易用，前后端解耦，扩展性高等优点。使用ZERO COPY也能大幅提升性能。可以很容易地整合到复杂的虚拟Crypto资源服务的应用中。然而，由于Virtio Crypto的LINUX驱动及QEMU PROXY的局限性，目前仅支持AES-CBC和SHA1-MAC算法。随着未来支持算法的增加，Vhost-Crypto也会不断发展壮大。

为解决LKCF的性能拖慢问题，我们在DPDK的Cryptodev Framework中加入了基于Virtio User的Virtio-Crypto PMD。关于DPDK Cryptodev Framework的介绍已在曾经的公众号文章中详细介绍过，这里就不在赘述了。该PMD和其他的DPDK Crypto PMD共享相同的控制面和数据面API，区别是其工作在虚拟机或者容器中。

要使用它，我们首先需要将Vhost Crypto应用启动并使其创建UNIX socket file，并将其有Qemu传递给VM。QEMU命令范例如下。

在VM中，该设备将被Linux Kernel默认绑定为一个Virtio Crypto设备。我们需要将QEMU传递上来的virtio设备绑定为UIO-PCI-GENERIC驱动。假设该设备拥有0000:00:04.0的PCI地址，我们可通过如下命令来将其改绑定。

然后，我们就能将其像其他Cryptodev PMD一样在DPDK中使用，并能享受HOST端的加速了。