From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 56CD51CA76 for ; Thu, 5 Apr 2018 11:48:45 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8BF5A8424D; Thu, 5 Apr 2018 09:48:44 +0000 (UTC) Received: from [10.36.112.61] (ovpn-112-61.ams2.redhat.com [10.36.112.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F0E092166BAE; Thu, 5 Apr 2018 09:48:42 +0000 (UTC) From: Maxime Coquelin To: Fan Zhang , dev@dpdk.org Cc: jianjay.zhou@huawei.com, jianfeng.tan@intel.com, pawelx.wodkowski@intel.com, Jens Freimann References: <20180404100902.27637-1-roy.fan.zhang@intel.com> <20180404142504.31836-1-roy.fan.zhang@intel.com> <0056f003-4c46-1ac7-c039-da60f72b1680@redhat.com> Message-ID: <73c715b9-24d9-3fdc-770c-9b2de7703c95@redhat.com> Date: Thu, 5 Apr 2018 11:48:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0056f003-4c46-1ac7-c039-da60f72b1680@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 05 Apr 2018 09:48:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 05 Apr 2018 09:48:44 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'maxime.coquelin@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [PATCH v6 0/8] vhost: introduce vhost crypto backend X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 09:48:45 -0000 On 04/05/2018 10:26 AM, Maxime Coquelin wrote: > > > On 04/04/2018 04:24 PM, Fan Zhang wrote: >> This patchset adds crypto backend suppport to vhost library >> including a proof-of-concept sample application. The implementation >> follows the virtio-crypto specification and have been tested >> with qemu 2.11.50 (with several patches applied, detailed later) >> with Fedora 24 running in the frontend. >> >> The vhost_crypto library acts as a "bridge" method that translate >> the virtio-crypto crypto requests to DPDK crypto operations, so it >> is purely software implementation. However it does require the user >> to provide the DPDK Cryptodev ID so it knows how to handle the >> virtio-crypto session creation and deletion mesages. >> >> Currently the implementation supports AES-CBC-128 and HMAC-SHA1 >> cipher only/chaining modes and does not support sessionless mode >> yet. The guest can use standard virtio-crypto driver to set up >> session and sends encryption/decryption requests to backend. The >> vhost-crypto sample application provided in this patchset will >> do the actual crypto work. >> >> The following steps are involved to enable vhost-crypto support. >> >> In the host: >> 1. Download the qemu source code. >> >> 2. Recompile your qemu with vhost-crypto option enabled. >> >> 3. Apply this patchset to latest DPDK code and recompile DPDK. >> >> 4. Compile and run vhost-crypto sample application. >> >> ./examples/vhost_crypto/build/vhost-crypto -l 11,12 -w 0000:86:01.0 \ >>   --socket-mem 2048,2048 >> >> Where 0000:86:01.0 is the QAT PCI address. You may use AES-NI-MB if it is >> not available. The sample application requires 2 lcores: 1 master and 1 >> worker. The application will create a UNIX socket file >> /tmp/vhost_crypto1.socket. >> >> 5. Start your qemu application. Here is my command: >> >> qemu/x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -cpu host \ >> -smp 2 -m 1G -hda ~/path-to-your/image.qcow \ >> -object >> memory-backend-file,id=mem,size=1G,mem-path=/dev/hugepages,share=on \ >> -mem-prealloc -numa node,memdev=mem -chardev \ >> socket,id=charcrypto0,path=/tmp/vhost_crypto1.socket \ >> -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0 \ >> -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 >> >> 6. Once guest is booted. The Linux virtio_crypto kernel module is >> loaded by >> default. You shall see the following logs in your demsg: >> >> [   17.611044] virtio_crypto: loading out-of-tree module taints kernel. >> [   17.611083] virtio_crypto: module verification failed: signature >> and/or ... >> [   17.611723] virtio_crypto virtio0: max_queues: 1, >> max_cipher_key_len: ... >> [   17.612156] virtio_crypto virtio0: will run requests pump with >> realtime ... >> [   18.376100] virtio_crypto virtio0: Accelerator is ready >> >> The virtio_crypto driver in the guest is now up and running. >> >> 7. The rest steps can be as same as the Testing section in >> https://wiki.qemu.org/Features/VirtioCrypto >> >> 8. It is possible to use DPDK Virtio Crypto PMD >> (https://dpdk.org/dev/patchwork/patch/36921/) in the guest to work with >> this patchset to achieve optimal performance. >> >> v6: >> - Changed commit message >> - removed rte prefix in handler prototype >> >> v5: >> - removed external ops register API. >> - patch cleaned. >> >> v4: >> - Changed external vhost backend ops register API. >> - Fixed a bug. >> >> v3: >> - Changed external vhost backend private data and message handling >> - Added experimental tag to rte_vhost_crypto_set_zero_copy() >> >> v2: >> - Moved vhost_crypto_data_req data from crypto op to source mbuf. >> - Removed ZERO-COPY flag from config option and make it run-timely >> changeable. >> - Guest-polling mode possible. >> - Simplified vring descriptor access procedure. >> - Work with both LKCF and DPDK Virtio-Crypto PMD guest drivers. >> >> Fan Zhang (8): >>    lib/librte_vhost: add vhost user message handlers >>    lib/librte_vhost: add virtio-crypto user message structure >>    lib/librte_vhost: add session message handler >>    lib/librte_vhost: add request handler >>    lib/librte_vhost: add public function implementation >>    lib/librte_vhost: update makefile >>    examples/vhost_crypto: add vhost crypto sample application >>    doc: update for vhost crypto support >> >>   doc/guides/prog_guide/vhost_lib.rst       |   25 + >>   doc/guides/rel_notes/release_18_05.rst    |    5 + >>   doc/guides/sample_app_ug/index.rst        |    1 + >>   doc/guides/sample_app_ug/vhost_crypto.rst |   82 ++ >>   examples/vhost_crypto/Makefile            |   32 + >>   examples/vhost_crypto/main.c              |  541 ++++++++++++ >>   examples/vhost_crypto/meson.build         |   14 + >>   lib/librte_vhost/Makefile                 |    6 +- >>   lib/librte_vhost/meson.build              |    8 +- >>   lib/librte_vhost/rte_vhost_crypto.h       |  109 +++ >>   lib/librte_vhost/rte_vhost_version.map    |   11 + >>   lib/librte_vhost/vhost.c                  |    2 +- >>   lib/librte_vhost/vhost.h                  |   53 +- >>   lib/librte_vhost/vhost_crypto.c           | 1312 >> +++++++++++++++++++++++++++++ >>   lib/librte_vhost/vhost_user.c             |   33 +- >>   lib/librte_vhost/vhost_user.h             |   35 +- >>   16 files changed, 2256 insertions(+), 13 deletions(-) >>   create mode 100644 doc/guides/sample_app_ug/vhost_crypto.rst >>   create mode 100644 examples/vhost_crypto/Makefile >>   create mode 100644 examples/vhost_crypto/main.c >>   create mode 100644 examples/vhost_crypto/meson.build >>   create mode 100644 lib/librte_vhost/rte_vhost_crypto.h >>   create mode 100644 lib/librte_vhost/vhost_crypto.c >> > > Applied to dpdk-next-virtio/master. Sorry, but I had to revert because it fails to build with older Kernels: fatal error: linux/virtio_crypto.h: No such file or directory Please fix it, fix the typo, and take the opportunity to rebase the series on top of dpdk-next-virtio/master. Note that you were also missing _rte_experimental in front of some of the new APIs. Thanks in advance, Maxime > Fan, I had quite a few conflicts to solve due to vDPA series. > > Can you please a trial of vhost crypto usecase and confirm this is all > good? > > Thanks, > Maxime