List comments

GET /api/covers/54954/comments/
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

[
    {
        "id": 97340,
        "web_url": "http://patches.dpdk.org/comment/97340/",
        "msgid": "<e84d27e6-d494-547d-2151-5bc9be96626c@samsung.com>",
        "date": "2019-06-20T11:32:39",
        "subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
        "submitter": {
            "id": 323,
            "url": "http://patches.dpdk.org/api/people/323/",
            "name": "Ilya Maximets",
            "email": "i.maximets@samsung.com"
        },
        "content": "On 19.06.2019 18:14, Nikos Dragazis wrote:\n> Hi everyone,\n\nHi. I didn't look at the code, just a few comments inline.\n\n> \n> this patch series introduces the concept of the virtio-vhost-user\n> transport. This is actually a revised version of an earlier RFC\n> implementation that has been proposed by Stefan Hajnoczi [1]. Though\n> this is a great feature, it seems to have been stalled, so I’d like to\n> restart the conversation on this and hopefully get it merged with your\n> help. Let me give you an overview.\n> \n> The virtio-vhost-user transport is a vhost-user transport implementation\n> that is based on the virtio-vhost-user device. Its key difference with\n> the existing transport is that it allows deploying vhost-user targets\n> inside dedicated Storage Appliance VMs instead of host user space. In\n> other words, it allows having guests that act as vhost-user backends for\n> other guests.\n> \n> The virtio-vhost-user device implements the vhost-user control plane\n> (master-slave communication) as follows:\n> \n> 1. it parses the vhost-user messages from the vhost-user unix domain\n>    socket and forwards them to the slave guest through virtqueues\n> \n> 2. it maps the vhost memory regions in QEMU’s process address space and\n>    exposes them to the slave guest as a RAM-backed PCI MMIO region\n> \n> 3. it hooks up doorbells to the callfds. The slave guest can use these\n>    doorbells to interrupt the master guest driver\n> \n> The device code has not yet been merged into upstream QEMU, but this is\n> definitely the end goal. The current state is that we are awaiting for\n> the approval of the virtio spec.\n> \n> I have Cced Darek from the SPDK community who has helped me a lot by\n> reviewing this series. Note that any device type could be implemented\n> over this new transport. So, adding the virtio-vhost-user transport in\n> DPDK would allow using it from SPDK as well.\n> \n> Getting into the code internals, this patch series makes the following\n> changes:\n> \n> 1. introduce a generic interface for the transport-specific operations.\n>    Each of the two available transports, the pre-existing AF_UNIX\n>    transport and the virtio-vhost-user transport, is going to implement\n>    this interface. The AF_UNIX-specific code has been extracted from the\n>    core vhost-user code and is now part of the AF_UNIX transport\n>    implementation in trans_af_unix.c.\n> \n> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user\n>    transport requires a driver for the virtio-vhost-user devices. The\n>    driver along with the transport implementation have been packed into\n>    a separate library in `drivers/virtio_vhost_user/`. The necessary\n>    virtio-pci code has been copied from `drivers/net/virtio/`. Some\n>    additional changes have been made so that the driver can utilize the\n>    additional resources of the virtio-vhost-user device.\n> \n> 3. update librte_vhost public API to enable choosing transport for each\n>    new vhost device. Extend the vhost net driver and vhost-scsi example\n>    application to export this new API to the end user.\n> \n> The primary changes I did to Stefan’s RFC implementation are the\n> following:\n> \n> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy\n>    live migration relies on the userfault fd mechanism, which cannot be\n>    supported by virtio-vhost-user.\n> \n> 2. moved setup of the log memory region into trans_af_unix.c. Setting up\n>    the log memory region involves mapping/unmapping guest memory. This\n>    is an AF_UNIX transport-specific operation.\n\nLogging dirty pages is the main concept of live migration support. Does it\nmean that the live migration is not supported for virtio-vhost-user at all?\n\n> \n> 3. introduced a vhost transport operation for\n>    process_slave_message_reply()\n> \n> 4. moved the virtio-vhost-user transport/driver into a separate library\n>    in `drivers/virtio_vhost_user/`. This required making vhost.h and\n>    vhost_user.h part of librte_vhost public API and exporting some\n>    private symbols via the version script. This looks better to me that\n>    just moving the entire librte_vhost into `drivers/`. I am not sure if\n>    this is the most appropriate solution. I am looking forward to your\n>    suggestions on this.\n\nMoving the virtio-vhost-user code to a separate driver looks strange for me.\nWhat is the purpose?\n\nExporting a lot of vhost internal structures will lead to a frequent API/ABI\nbreakages and will slow down accepting changes to releases in general.\n\nIt looks inconsistent to have 'trans_af_unix.c' in 'lib/librte_vhost/' and\n'trans_virtio_vhost_user.c' in 'drivers/virtio_vhost_user/' because these\nfiles should be similar in provided functionality, hence, should be located\nin similar places.\n\n> \n> 5. made use of the virtio PCI capabilities for the additional device\n>    resources (doorbells, shared memory). This required changes in\n>    virtio_pci.c and trans_virtio_vhost_user.c.\n> \n> 6. [minor] changed some commit headlines to comply with\n>    check-git-log.sh.\n> \n> Please, have a look and let me know about your thoughts. Any\n> reviews/pointers/suggestions are welcome.\n> \n> Best regards,\n> Nikos\n> \n> [1] http://mails.dpdk.org/archives/dev/2018-January/088155.html\n> \n> \n> Nikos Dragazis (23):\n>   vhost: introduce vhost transport operations structure\n>   vhost: move socket management code\n>   vhost: move socket fd and un sockaddr\n>   vhost: move vhost-user connection\n>   vhost: move vhost-user reconnection\n>   vhost: move vhost-user fdset\n>   vhost: propagate vhost transport operations\n>   vhost: use a single structure for the device state\n>   vhost: extract socket I/O into transport\n>   vhost: move slave request fd and lock\n>   vhost: move mmap/munmap\n>   vhost: move setup of the log memory region\n>   vhost: remove main fd parameter from msg handlers\n>   vhost: move postcopy live migration code\n>   vhost: support registering additional vhost-user transports\n>   drivers/virtio_vhost_user: add virtio PCI framework\n>   drivers: add virtio-vhost-user transport\n>   drivers/virtio_vhost_user: use additional device resources\n>   vhost: add flag for choosing vhost-user transport\n>   net/vhost: add virtio-vhost-user support\n>   mk: link apps with virtio-vhost-user driver\n>   config: add option for the virtio-vhost-user transport\n>   usertools: add virtio-vhost-user devices to dpdk-devbind.py\n> \n> Stefan Hajnoczi (5):\n>   vhost: allocate per-socket transport state\n>   vhost: move start server/client calls\n>   vhost: add index field in vhost virtqueues\n>   examples/vhost_scsi: add --socket-file argument\n>   examples/vhost_scsi: add virtio-vhost-user support\n> \n>  config/common_base                                 |    6 +\n>  config/common_linux                                |    1 +\n>  drivers/Makefile                                   |    5 +\n>  drivers/net/vhost/rte_eth_vhost.c                  |   13 +\n>  drivers/virtio_vhost_user/Makefile                 |   27 +\n>  .../rte_virtio_vhost_user_version.map              |    4 +\n>  .../virtio_vhost_user/trans_virtio_vhost_user.c    | 1077 +++++++++++++++++++\n>  drivers/virtio_vhost_user/virtio_pci.c             |  520 ++++++++++\n>  drivers/virtio_vhost_user/virtio_pci.h             |  289 ++++++\n>  drivers/virtio_vhost_user/virtio_vhost_user.h      |   18 +\n>  drivers/virtio_vhost_user/virtqueue.h              |  181 ++++\n>  examples/vhost_scsi/vhost_scsi.c                   |  103 +-\n>  lib/librte_vhost/Makefile                          |    4 +-\n>  lib/librte_vhost/rte_vhost.h                       |    1 +\n>  lib/librte_vhost/rte_vhost_version.map             |   11 +\n>  lib/librte_vhost/socket.c                          |  685 +-----------\n>  lib/librte_vhost/trans_af_unix.c                   | 1094 ++++++++++++++++++++\n>  lib/librte_vhost/vhost.c                           |   22 +-\n>  lib/librte_vhost/vhost.h                           |  298 +++++-\n>  lib/librte_vhost/vhost_user.c                      |  474 ++-------\n>  lib/librte_vhost/vhost_user.h                      |   10 +-\n>  mk/rte.app.mk                                      |    6 +\n>  usertools/dpdk-devbind.py                          |    7 +\n>  23 files changed, 3764 insertions(+), 1092 deletions(-)\n>  create mode 100644 drivers/virtio_vhost_user/Makefile\n>  create mode 100644 drivers/virtio_vhost_user/rte_virtio_vhost_user_version.map\n>  create mode 100644 drivers/virtio_vhost_user/trans_virtio_vhost_user.c\n>  create mode 100644 drivers/virtio_vhost_user/virtio_pci.c\n>  create mode 100644 drivers/virtio_vhost_user/virtio_pci.h\n>  create mode 100644 drivers/virtio_vhost_user/virtio_vhost_user.h\n>  create mode 100644 drivers/virtio_vhost_user/virtqueue.h\n>  create mode 100644 lib/librte_vhost/trans_af_unix.c\n>",
        "headers": {
            "List-Id": "DPDK patches and discussions <dev.dpdk.org>",
            "From": "Ilya Maximets <i.maximets@samsung.com>",
            "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
            "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;\n\ts=mail20170921; t=1561030361;\n\tbh=48VLxZd93glWCyVP46wb6/2PGUq71NhpBKzFKD4oLDU=;\n\th=Subject:To:Cc:From:Date:In-Reply-To:References:From;\n\tb=OlijliSVxq5Xum+8rLcFMUf0eAaBl6mSpENpX0zC8xjqJJ0MKr0AVsKZ99AxALrZG\n\tUySZHQ6gxQpugKOznfHBxi+13pjqgtorBTkaaGYo+8ozzzShLgXCD9S3Bnpaf6AQ03\n\tCa+HH0f+aaO99hVrjF4ZmvsBZGn2NGCfU2Vj99Xs=",
            "X-BeenThere": "dev@dpdk.org",
            "X-Mailman-Version": "2.1.15",
            "Delivered-To": "patchwork@dpdk.org",
            "X-AuditID": "cbfec7f5-b75ff700000010e5-83-5d0b6ed8a183",
            "List-Archive": "<http://mails.dpdk.org/archives/dev/>",
            "X-CMS-MailID": "20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56",
            "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>",
            "X-RootMTR": "20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56",
            "Cc": "Maxime Coquelin <maxime.coquelin@redhat.com>, Tiwei Bie\n\t<tiwei.bie@intel.com>, Zhihong Wang <zhihong.wang@intel.com>, Stefan\n\tHajnoczi <stefanha@redhat.com>, Wei Wang <wei.w.wang@intel.com>,\n\tStojaczyk Dariusz <dariusz.stojaczyk@intel.com>,\n\tVangelis Koukis <vkoukis@arrikto.com>",
            "To": "Nikos Dragazis <ndragazis@arrikto.com>, dev@dpdk.org",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101\n\tThunderbird/60.7.0",
            "References": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>\n\t<CGME20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56@eucas1p2.samsung.com>",
            "CMS-TYPE": "201P",
            "Return-Path": "<dev-bounces@dpdk.org>",
            "DKIM-Filter": "OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com\n\t20190620113241euoutp02d6834d35143a130af020f840dce3fa05~p5Nfp5cDt2500125001euoutp02g",
            "Errors-To": "dev-bounces@dpdk.org",
            "X-EPHeader": "CA",
            "List-Post": "<mailto:dev@dpdk.org>",
            "Received": [
                "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 2F5CC1D37B;\n\tThu, 20 Jun 2019 13:32:44 +0200 (CEST)",
                "from mailout2.w1.samsung.com (mailout2.w1.samsung.com\n\t[210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 3BFA71D378\n\tfor <dev@dpdk.org>; Thu, 20 Jun 2019 13:32:42 +0200 (CEST)",
                "from eucas1p1.samsung.com (unknown [182.198.249.206])\n\tby mailout2.w1.samsung.com (KnoxPortal) with ESMTP id\n\t20190620113241euoutp02d6834d35143a130af020f840dce3fa05~p5Nfp5cDt2500125001euoutp02g\n\tfor <dev@dpdk.org>; Thu, 20 Jun 2019 11:32:41 +0000 (GMT)",
                "from eusmges3new.samsung.com (unknown [203.254.199.245]) by\n\teucas1p1.samsung.com (KnoxPortal) with ESMTP id\n\t20190620113241eucas1p1fb4442f88e33b314640ebc6f8ed0a3cc~p5NfMDJk11366013660eucas1p1s;\n\tThu, 20 Jun 2019 11:32:41 +0000 (GMT)",
                "from eucas1p1.samsung.com ( [182.198.249.206]) by\n\teusmges3new.samsung.com (EUCPMTA) with SMTP id 9E.BD.04325.8DE6B0D5;\n\tThu, 20 Jun 2019 12:32:41 +0100 (BST)",
                "from eusmtrp2.samsung.com (unknown [182.198.249.139]) by\n\teucas1p2.samsung.com (KnoxPortal) with ESMTPA id\n\t20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56~p5NeRzudR1689616896eucas1p2T;\n\tThu, 20 Jun 2019 11:32:40 +0000 (GMT)",
                "from eusmgms2.samsung.com (unknown [182.198.249.180]) by\n\teusmtrp2.samsung.com (KnoxPortal) with ESMTP id\n\t20190620113240eusmtrp2708f972a20900df2b9b056ee8695195e~p5NeRNxOY2288822888eusmtrp2L;\n\tThu, 20 Jun 2019 11:32:40 +0000 (GMT)",
                "from eusmtip1.samsung.com ( [203.254.199.221]) by\n\teusmgms2.samsung.com (EUCPMTA) with SMTP id 94.5E.04140.8DE6B0D5;\n\tThu, 20 Jun 2019 12:32:40 +0100 (BST)",
                "from [106.109.129.180] (unknown [106.109.129.180]) by\n\teusmtip1.samsung.com (KnoxPortal) with ESMTPA id\n\t20190620113239eusmtip19857627698ab3f5b7cf5ddfc0bb4025d~p5NdslJ680139401394eusmtip1k;\n\tThu, 20 Jun 2019 11:32:39 +0000 (GMT)"
            ],
            "Content-Language": "en-GB",
            "Date": "Thu, 20 Jun 2019 14:32:39 +0300",
            "Content-Type": "text/plain; charset=\"utf-8\"",
            "Sender": "\"dev\" <dev-bounces@dpdk.org>",
            "Subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
            "In-Reply-To": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>",
            "MIME-Version": "1.0",
            "Message-ID": "<e84d27e6-d494-547d-2151-5bc9be96626c@samsung.com>",
            "Precedence": "list",
            "X-Brightmail-Tracker": [
                "H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsWy7djPc7o387hjDSZOY7R4/3sNo8W7T9uZ\n\tLK60/2S3ONa5h8ViSfsVFovXk/6zWmxt+M9kcfb3I2aL33MvMFpsvjiJyYHL4+ajj4wevxYs\n\tZfVYvOclk8f7fVfZPPq2rGIMYI3isklJzcksSy3St0vgyni1OqzggWtFz+4LbA2Mu0y7GDk4\n\tJARMJNa1SncxcnEICaxglFg7dQMLhPOFUeLbxiYghxPI+cwosfUTP0zDhr8cEDXLGSV+vLnK\n\tDOF8ZJRYveEfWIOwgI/EgilzwGwRAQuJy+t/sYEUMQvMY5KYNnMmK0iCTUBH4tTqI4wgU3kF\n\t7CQmfDUFCbMIqEq8/D+ZHcQWFYiQ+LJzEyOIzSsgKHFy5hOwmZwCbhJ7ts9nA7GZBcQlmr6s\n\tZIWw5SWat84GO0hC4BS7xIrHb5lAEhICLhK/HvQyQtjCEq+Ob2GHsGUk/u+cD1VTL3G/5SUj\n\tRHMHo8T0Q/+gEvYSW16fYwc5lFlAU2L9Ln2IsKPEzi2PmSGhwidx460gxA18EpO2TYcK80p0\n\ttAlBVKtI/D64nBnClpK4+e4z+wRGpVlIPpuF5JtZSL6ZhbB3ASPLKkbx1NLi3PTUYuO81HK9\n\t4sTc4tK8dL3k/NxNjMDkdPrf8a87GPf9STrEKMDBqMTDe0KLK1aINbGsuDL3EKMEB7OSCO9T\n\tRu5YId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzVDA+ihQTSE0tSs1NTC1KLYLJMHJxSDYzc/+Zm\n\tOVm5B846wiWvVi07a29kR36vRNGjiiOzU6OPaXctZROvy/N7JHTCOkD2ZVxNeeNCbu7q6oD7\n\tUh897kz5bsRrx/1D5U+a5myuuqA199NOPD8ra/5F6avkm92m9dWzNxiFfDUS/DLxg/j/FboW\n\tPsl/ku9ND31zKznoZlLdipPC+vVhgUosxRmJhlrMRcWJANXf2exKAwAA",
                "H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsVy+t/xu7o38rhjDQ73iFq8/72G0eLdp+1M\n\tFlfaf7JbHOvcw2KxpP0Ki8XrSf9ZLbY2/GeyOPv7EbPF77kXGC02X5zE5MDlcfPRR0aPXwuW\n\tsnos3vOSyeP9vqtsHn1bVjEGsEbp2RTll5akKmTkF5fYKkUbWhjpGVpa6BmZWOoZGpvHWhmZ\n\tKunb2aSk5mSWpRbp2yXoZbxaHVbwwLWiZ/cFtgbGXaZdjBwcEgImEhv+cnQxcnEICSxllPja\n\tuIC5i5ETKC4l8ePXBVYIW1jiz7UuNoii94wSx94dZAdJCAv4SCyYMocFxBYRsJC4vP4XG4jN\n\tLLCASWLKAk8QW0jAVeLfzylMIDabgI7EqdVHGEEW8wrYSUz4agoSZhFQlXj5fzLYSFGBCInZ\n\tuxrARvIKCEqcnPkEzOYUcJPYs30+1Hh1iT/zLjFD2OISTV9WskLY8hLNW2czT2AUmoWkfRaS\n\tlllIWmYhaVnAyLKKUSS1tDg3PbfYSK84Mbe4NC9dLzk/dxMjMB63Hfu5ZQdj17vgQ4wCHIxK\n\tPLwntLhihVgTy4orcw8xSnAwK4nwPmXkjhXiTUmsrEotyo8vKs1JLT7EaAr03ERmKdHkfGCq\n\tyCuJNzQ1NLewNDQ3Njc2s1AS5+0QOBgjJJCeWJKanZpakFoE08fEwSnVwNh5IyLE7vLBLdOj\n\tzTP8Py0u5Ty1UdUk7nOcja9t0WLXmMPXj2S387ntzZZPPbTysC2HsjrzaRlroal7c7uUVhzl\n\trRDS7f2v71Sg0hPDHhJ3d/KO/d+NU/681H+z2CrzxSz9U79WHQ76nV5f+VN9ad3euhk8+o3p\n\t4R8tuox+3Zxt5r328/mFmkosxRmJhlrMRcWJAHU2BAvdAgAA"
            ],
            "Content-Transfer-Encoding": "8bit",
            "X-Msg-Generator": "CA",
            "X-CMS-RootMailID": "20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56",
            "X-Original-To": "patchwork@dpdk.org",
            "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>"
        }
    },
    {
        "id": 97341,
        "web_url": "http://patches.dpdk.org/comment/97341/",
        "msgid": "<d9a8eb71-b417-342b-7afb-5063b807cafb@redhat.com>",
        "date": "2019-06-20T11:35:13",
        "subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
        "submitter": {
            "id": 512,
            "url": "http://patches.dpdk.org/api/people/512/",
            "name": "Maxime Coquelin",
            "email": "maxime.coquelin@redhat.com"
        },
        "content": "Hi Nikos,\n\nOn 6/19/19 5:14 PM, Nikos Dragazis wrote:\n> Hi everyone,\n> \n> this patch series introduces the concept of the virtio-vhost-user\n> transport. This is actually a revised version of an earlier RFC\n> implementation that has been proposed by Stefan Hajnoczi [1]. Though\n> this is a great feature, it seems to have been stalled, so I’d like to\n> restart the conversation on this and hopefully get it merged with your\n> help. Let me give you an overview.\n\nThanks for taking over the series!\n\nI think you are already aware of that, but it arrives too late to\nconsider it for v19.08, as the proposal deadline is over by almost 3\nweeks.\n\nThat said, it is good that you sent it early, so that we can work to\nmake it in for v19.11.\n\n> The virtio-vhost-user transport is a vhost-user transport implementation\n> that is based on the virtio-vhost-user device. Its key difference with\n> the existing transport is that it allows deploying vhost-user targets\n> inside dedicated Storage Appliance VMs instead of host user space. In\n> other words, it allows having guests that act as vhost-user backends for\n> other guests.\n> \n> The virtio-vhost-user device implements the vhost-user control plane\n> (master-slave communication) as follows:\n> \n> 1. it parses the vhost-user messages from the vhost-user unix domain\n>     socket and forwards them to the slave guest through virtqueues\n> \n> 2. it maps the vhost memory regions in QEMU’s process address space and\n>     exposes them to the slave guest as a RAM-backed PCI MMIO region\n> \n> 3. it hooks up doorbells to the callfds. The slave guest can use these\n>     doorbells to interrupt the master guest driver\n> \n> The device code has not yet been merged into upstream QEMU, but this is\n> definitely the end goal.\n\nCould you provide a pointer to the QEMU series, and instructions to test\nthis new device?\n\n> The current state is that we are awaiting for\n> the approval of the virtio spec.\n\nDitto, a link to the spec patches would be useful.\n\n> I have Cced Darek from the SPDK community who has helped me a lot by\n> reviewing this series. Note that any device type could be implemented\n> over this new transport. So, adding the virtio-vhost-user transport in\n> DPDK would allow using it from SPDK as well.\n> \n> Getting into the code internals, this patch series makes the following\n> changes:\n> \n> 1. introduce a generic interface for the transport-specific operations.\n>     Each of the two available transports, the pre-existing AF_UNIX\n>     transport and the virtio-vhost-user transport, is going to implement\n>     this interface. The AF_UNIX-specific code has been extracted from the\n>     core vhost-user code and is now part of the AF_UNIX transport\n>     implementation in trans_af_unix.c.\n> \n> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user\n>     transport requires a driver for the virtio-vhost-user devices. The\n>     driver along with the transport implementation have been packed into\n>     a separate library in `drivers/virtio_vhost_user/`. The necessary\n>     virtio-pci code has been copied from `drivers/net/virtio/`. Some\n>     additional changes have been made so that the driver can utilize the\n>     additional resources of the virtio-vhost-user device.\n> \n> 3. update librte_vhost public API to enable choosing transport for each\n>     new vhost device. Extend the vhost net driver and vhost-scsi example\n>     application to export this new API to the end user.\n> \n> The primary changes I did to Stefan’s RFC implementation are the\n> following:\n> \n> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy\n>     live migration relies on the userfault fd mechanism, which cannot be\n>     supported by virtio-vhost-user.\n> \n> 2. moved setup of the log memory region into trans_af_unix.c. Setting up\n>     the log memory region involves mapping/unmapping guest memory. This\n>     is an AF_UNIX transport-specific operation.\n> \n> 3. introduced a vhost transport operation for\n>     process_slave_message_reply()\n> \n> 4. moved the virtio-vhost-user transport/driver into a separate library\n>     in `drivers/virtio_vhost_user/`. This required making vhost.h and\n>     vhost_user.h part of librte_vhost public API and exporting some\n>     private symbols via the version script. This looks better to me that\n>     just moving the entire librte_vhost into `drivers/`. I am not sure if\n>     this is the most appropriate solution. I am looking forward to your\n>     suggestions on this.\n\nI'm not sure this is the right place to put it.\n\n> 5. made use of the virtio PCI capabilities for the additional device\n>     resources (doorbells, shared memory). This required changes in\n>     virtio_pci.c and trans_virtio_vhost_user.c.\n> \n> 6. [minor] changed some commit headlines to comply with\n>     check-git-log.sh.\n> \n> Please, have a look and let me know about your thoughts. Any\n> reviews/pointers/suggestions are welcome.\n\nMaxime",
        "headers": {
            "List-Id": "DPDK patches and discussions <dev.dpdk.org>",
            "From": "Maxime Coquelin <maxime.coquelin@redhat.com>",
            "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
            "Date": "Thu, 20 Jun 2019 13:35:13 +0200",
            "X-Mailman-Version": "2.1.15",
            "Delivered-To": "patchwork@dpdk.org",
            "List-Archive": "<http://mails.dpdk.org/archives/dev/>",
            "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>",
            "Cc": "Tiwei Bie <tiwei.bie@intel.com>, Zhihong Wang <zhihong.wang@intel.com>, \n\tStefan Hajnoczi <stefanha@redhat.com>, Wei Wang <wei.w.wang@intel.com>, \n\tStojaczyk Dariusz <dariusz.stojaczyk@intel.com>,\n\tVangelis Koukis <vkoukis@arrikto.com>",
            "To": "Nikos Dragazis <ndragazis@arrikto.com>, dev@dpdk.org",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101\n\tThunderbird/60.6.1",
            "References": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>",
            "Sender": "\"dev\" <dev-bounces@dpdk.org>",
            "Return-Path": "<dev-bounces@dpdk.org>",
            "Errors-To": "dev-bounces@dpdk.org",
            "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>",
            "List-Post": "<mailto:dev@dpdk.org>",
            "Received": [
                "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 976251D389;\n\tThu, 20 Jun 2019 13:35:23 +0200 (CEST)",
                "from mx1.redhat.com (mx1.redhat.com [209.132.183.28])\n\tby dpdk.org (Postfix) with ESMTP id 424B61D37B\n\tfor <dev@dpdk.org>; Thu, 20 Jun 2019 13:35:22 +0200 (CEST)",
                "from smtp.corp.redhat.com\n\t(int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id A3C3A3B714;\n\tThu, 20 Jun 2019 11:35:21 +0000 (UTC)",
                "from [10.36.112.46] (ovpn-112-46.ams2.redhat.com [10.36.112.46])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 253C619C4F;\n\tThu, 20 Jun 2019 11:35:14 +0000 (UTC)"
            ],
            "X-Original-To": "patchwork@dpdk.org",
            "Content-Language": "en-US",
            "Content-Type": "text/plain; charset=utf-8; format=flowed",
            "X-Scanned-By": "MIMEDefang 2.84 on 10.5.11.23",
            "Subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
            "In-Reply-To": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>",
            "MIME-Version": "1.0",
            "Message-ID": "<d9a8eb71-b417-342b-7afb-5063b807cafb@redhat.com>",
            "Precedence": "list",
            "Content-Transfer-Encoding": "8bit",
            "X-BeenThere": "dev@dpdk.org",
            "X-Greylist": "Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]); Thu, 20 Jun 2019 11:35:21 +0000 (UTC)"
        }
    },
    {
        "id": 97375,
        "web_url": "http://patches.dpdk.org/comment/97375/",
        "msgid": "<8e969352-27d2-1a61-d545-0acf37c65af4@arrikto.com>",
        "date": "2019-06-20T23:44:30",
        "subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
        "submitter": {
            "id": 1339,
            "url": "http://patches.dpdk.org/api/people/1339/",
            "name": "Nikos Dragazis",
            "email": "ndragazis@arrikto.com"
        },
        "content": "On 20/6/19 2:32 μ.μ., Ilya Maximets wrote:\n> On 19.06.2019 18:14, Nikos Dragazis wrote:\n>> Hi everyone,\n> Hi. I didn't look at the code, just a few comments inline.\n>\n>> this patch series introduces the concept of the virtio-vhost-user\n>> transport. This is actually a revised version of an earlier RFC\n>> implementation that has been proposed by Stefan Hajnoczi [1]. Though\n>> this is a great feature, it seems to have been stalled, so I’d like to\n>> restart the conversation on this and hopefully get it merged with your\n>> help. Let me give you an overview.\n>>\n>> The virtio-vhost-user transport is a vhost-user transport implementation\n>> that is based on the virtio-vhost-user device. Its key difference with\n>> the existing transport is that it allows deploying vhost-user targets\n>> inside dedicated Storage Appliance VMs instead of host user space. In\n>> other words, it allows having guests that act as vhost-user backends for\n>> other guests.\n>>\n>> The virtio-vhost-user device implements the vhost-user control plane\n>> (master-slave communication) as follows:\n>>\n>> 1. it parses the vhost-user messages from the vhost-user unix domain\n>>    socket and forwards them to the slave guest through virtqueues\n>>\n>> 2. it maps the vhost memory regions in QEMU’s process address space and\n>>    exposes them to the slave guest as a RAM-backed PCI MMIO region\n>>\n>> 3. it hooks up doorbells to the callfds. The slave guest can use these\n>>    doorbells to interrupt the master guest driver\n>>\n>> The device code has not yet been merged into upstream QEMU, but this is\n>> definitely the end goal. The current state is that we are awaiting for\n>> the approval of the virtio spec.\n>>\n>> I have Cced Darek from the SPDK community who has helped me a lot by\n>> reviewing this series. Note that any device type could be implemented\n>> over this new transport. So, adding the virtio-vhost-user transport in\n>> DPDK would allow using it from SPDK as well.\n>>\n>> Getting into the code internals, this patch series makes the following\n>> changes:\n>>\n>> 1. introduce a generic interface for the transport-specific operations.\n>>    Each of the two available transports, the pre-existing AF_UNIX\n>>    transport and the virtio-vhost-user transport, is going to implement\n>>    this interface. The AF_UNIX-specific code has been extracted from the\n>>    core vhost-user code and is now part of the AF_UNIX transport\n>>    implementation in trans_af_unix.c.\n>>\n>> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user\n>>    transport requires a driver for the virtio-vhost-user devices. The\n>>    driver along with the transport implementation have been packed into\n>>    a separate library in `drivers/virtio_vhost_user/`. The necessary\n>>    virtio-pci code has been copied from `drivers/net/virtio/`. Some\n>>    additional changes have been made so that the driver can utilize the\n>>    additional resources of the virtio-vhost-user device.\n>>\n>> 3. update librte_vhost public API to enable choosing transport for each\n>>    new vhost device. Extend the vhost net driver and vhost-scsi example\n>>    application to export this new API to the end user.\n>>\n>> The primary changes I did to Stefan’s RFC implementation are the\n>> following:\n>>\n>> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy\n>>    live migration relies on the userfault fd mechanism, which cannot be\n>>    supported by virtio-vhost-user.\n>>\n>> 2. moved setup of the log memory region into trans_af_unix.c. Setting up\n>>    the log memory region involves mapping/unmapping guest memory. This\n>>    is an AF_UNIX transport-specific operation.\n> Logging dirty pages is the main concept of live migration support. Does it\n> mean that the live migration is not supported for virtio-vhost-user at all?\n\nNo, it is supported. To be more precise, it can be supported, it is part\nof the on-going virtio device specification:\n\nhttps://lists.oasis-open.org/archives/virtio-dev/201905/msg00022.html\n\nand it is in my TODO list for the device code. Here is how it works:\n\nthe log memory region, just like the other vhost memory regions, is a\nportion of the master guest memory. In case of the AF_UNIX transport,\nthe master sends a VHOST_USER_SET_LOG_BASE message and the vhost target\nmmaps the log memory region into the process' virtual address space. In\ncase of the virtio-vhost-user transport, the virtio-vhost-user device\nparses the VHOST_USER_SET_LOG_BASE message and maps the log memory\nregion into QEMU's process address space. It then exposes the log memory\nregion to the slave guest as a RAM-backed PCI MMIO region.\n\nSo, from the vhost target's viewpoint, the only difference is the means\nof accessing the log memory region. In case of the AF_UNIX transport,\nthe vhost target receives a file descriptor and mmaps this file. In case\nof the virtio-vhost-user transport, the device exports the log memory\nregion to the vhost target (running in slave guest user space) via an\nMMIO BAR.\n\nTo recap, just to make sure it is clear, the virtio-vhost-user transport\ndoes support precopy live migration, but it doesn't support postcopy\nlive migration.\n\n>\n>> 3. introduced a vhost transport operation for\n>>    process_slave_message_reply()\n>>\n>> 4. moved the virtio-vhost-user transport/driver into a separate library\n>>    in `drivers/virtio_vhost_user/`. This required making vhost.h and\n>>    vhost_user.h part of librte_vhost public API and exporting some\n>>    private symbols via the version script. This looks better to me that\n>>    just moving the entire librte_vhost into `drivers/`. I am not sure if\n>>    this is the most appropriate solution. I am looking forward to your\n>>    suggestions on this.\n> Moving the virtio-vhost-user code to a separate driver looks strange for me.\n> What is the purpose?\n\nThe virtio-vhost-user transport is based on the virtio-vhost-user\ndevice. This means that we need a user space driver for this device\ntype.  Currently, the driver and the transport implementation are packed\ntogether into `trans_virtio_vhost_user.c`. There are 2 reasons why I\nmoved all the virtio-vhost-user code (driver + transport implementation)\ninto `drivers/`:\n\n1. my understanding is that all drivers should be located in `drivers/`.\n\n2. |the driver depends on `rte_bus_pci.h` which gets exported when\n   `drivers/` is built whereas librte_vhost is built before `drivers/`.\n   However, I think this could be overcomed by just adding this line:\n\n   CFLAGS += -I$(RTE_SDK)/drivers/bus/pci\n\n   in librte_vhost Makefile.||\n\n\n|\n>\n> Exporting a lot of vhost internal structures will lead to a frequent API/ABI\n> breakages and will slow down accepting changes to releases in general.\n\nI understand that there are many parameters that we have to consider. My\nimplementation is just a proposal.  I am looking forward to hearing from\nyou and the community any other suggestions on this.\n\n>\n> It looks inconsistent to have 'trans_af_unix.c' in 'lib/librte_vhost/' and\n> 'trans_virtio_vhost_user.c' in 'drivers/virtio_vhost_user/' because these\n> files should be similar in provided functionality, hence, should be located\n> in similar places.\n\nI agree. Actually, I was thinking about separating the driver from the\ntransport implementation and moving just the driver into `drivers/`. But\nthis would require exporting some low-level virtio PCI functions. And\nthis didn't look appropriate to me.\n\n>\n>> 5. made use of the virtio PCI capabilities for the additional device\n>>    resources (doorbells, shared memory). This required changes in\n>>    virtio_pci.c and trans_virtio_vhost_user.c.\n>>\n>> 6. [minor] changed some commit headlines to comply with\n>>    check-git-log.sh.\n>>\n>> Please, have a look and let me know about your thoughts. Any\n>> reviews/pointers/suggestions are welcome.\n>>\n>> Best regards,\n>> Nikos\n>>\n>> [1] http://mails.dpdk.org/archives/dev/2018-January/088155.html\n>>\n>>\n>> Nikos Dragazis (23):\n>>   vhost: introduce vhost transport operations structure\n>>   vhost: move socket management code\n>>   vhost: move socket fd and un sockaddr\n>>   vhost: move vhost-user connection\n>>   vhost: move vhost-user reconnection\n>>   vhost: move vhost-user fdset\n>>   vhost: propagate vhost transport operations\n>>   vhost: use a single structure for the device state\n>>   vhost: extract socket I/O into transport\n>>   vhost: move slave request fd and lock\n>>   vhost: move mmap/munmap\n>>   vhost: move setup of the log memory region\n>>   vhost: remove main fd parameter from msg handlers\n>>   vhost: move postcopy live migration code\n>>   vhost: support registering additional vhost-user transports\n>>   drivers/virtio_vhost_user: add virtio PCI framework\n>>   drivers: add virtio-vhost-user transport\n>>   drivers/virtio_vhost_user: use additional device resources\n>>   vhost: add flag for choosing vhost-user transport\n>>   net/vhost: add virtio-vhost-user support\n>>   mk: link apps with virtio-vhost-user driver\n>>   config: add option for the virtio-vhost-user transport\n>>   usertools: add virtio-vhost-user devices to dpdk-devbind.py\n>>\n>> Stefan Hajnoczi (5):\n>>   vhost: allocate per-socket transport state\n>>   vhost: move start server/client calls\n>>   vhost: add index field in vhost virtqueues\n>>   examples/vhost_scsi: add --socket-file argument\n>>   examples/vhost_scsi: add virtio-vhost-user support\n>>\n>>  config/common_base                                 |    6 +\n>>  config/common_linux                                |    1 +\n>>  drivers/Makefile                                   |    5 +\n>>  drivers/net/vhost/rte_eth_vhost.c                  |   13 +\n>>  drivers/virtio_vhost_user/Makefile                 |   27 +\n>>  .../rte_virtio_vhost_user_version.map              |    4 +\n>>  .../virtio_vhost_user/trans_virtio_vhost_user.c    | 1077 +++++++++++++++++++\n>>  drivers/virtio_vhost_user/virtio_pci.c             |  520 ++++++++++\n>>  drivers/virtio_vhost_user/virtio_pci.h             |  289 ++++++\n>>  drivers/virtio_vhost_user/virtio_vhost_user.h      |   18 +\n>>  drivers/virtio_vhost_user/virtqueue.h              |  181 ++++\n>>  examples/vhost_scsi/vhost_scsi.c                   |  103 +-\n>>  lib/librte_vhost/Makefile                          |    4 +-\n>>  lib/librte_vhost/rte_vhost.h                       |    1 +\n>>  lib/librte_vhost/rte_vhost_version.map             |   11 +\n>>  lib/librte_vhost/socket.c                          |  685 +-----------\n>>  lib/librte_vhost/trans_af_unix.c                   | 1094 ++++++++++++++++++++\n>>  lib/librte_vhost/vhost.c                           |   22 +-\n>>  lib/librte_vhost/vhost.h                           |  298 +++++-\n>>  lib/librte_vhost/vhost_user.c                      |  474 ++-------\n>>  lib/librte_vhost/vhost_user.h                      |   10 +-\n>>  mk/rte.app.mk                                      |    6 +\n>>  usertools/dpdk-devbind.py                          |    7 +\n>>  23 files changed, 3764 insertions(+), 1092 deletions(-)\n>>  create mode 100644 drivers/virtio_vhost_user/Makefile\n>>  create mode 100644 drivers/virtio_vhost_user/rte_virtio_vhost_user_version.map\n>>  create mode 100644 drivers/virtio_vhost_user/trans_virtio_vhost_user.c\n>>  create mode 100644 drivers/virtio_vhost_user/virtio_pci.c\n>>  create mode 100644 drivers/virtio_vhost_user/virtio_pci.h\n>>  create mode 100644 drivers/virtio_vhost_user/virtio_vhost_user.h\n>>  create mode 100644 drivers/virtio_vhost_user/virtqueue.h\n>>  create mode 100644 lib/librte_vhost/trans_af_unix.c\n>>",
        "headers": {
            "List-Id": "DPDK patches and discussions <dev.dpdk.org>",
            "From": "Nikos Dragazis <ndragazis@arrikto.com>",
            "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
            "Date": "Fri, 21 Jun 2019 02:44:30 +0300",
            "X-Mailman-Version": "2.1.15",
            "Delivered-To": "patchwork@dpdk.org",
            "List-Archive": "<http://mails.dpdk.org/archives/dev/>",
            "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>",
            "Cc": "dev@dpdk.org, Maxime Coquelin <maxime.coquelin@redhat.com>,\n\tTiwei Bie <tiwei.bie@intel.com>, Zhihong Wang <zhihong.wang@intel.com>,\n\tStefan Hajnoczi <stefanha@redhat.com>, Wei Wang <wei.w.wang@intel.com>,\n\tStojaczyk Dariusz <dariusz.stojaczyk@intel.com>,\n\tVangelis Koukis <vkoukis@arrikto.com>",
            "To": "Ilya Maximets <i.maximets@samsung.com>",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101\n\tThunderbird/60.7.0",
            "References": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>\n\t<CGME20190620113240eucas1p22ca4faa64a36bbb7aec38a81298ade56@eucas1p2.samsung.com>\n\t<e84d27e6-d494-547d-2151-5bc9be96626c@samsung.com>",
            "Sender": "\"dev\" <dev-bounces@dpdk.org>",
            "Return-Path": "<dev-bounces@dpdk.org>",
            "Errors-To": "dev-bounces@dpdk.org",
            "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>",
            "List-Post": "<mailto:dev@dpdk.org>",
            "Received": [
                "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id BE4691D3E9;\n\tFri, 21 Jun 2019 01:44:33 +0200 (CEST)",
                "from mx0.arrikto.com (mx0.arrikto.com [212.71.252.59])\n\tby dpdk.org (Postfix) with ESMTP id 79B7B1D3E6\n\tfor <dev@dpdk.org>; Fri, 21 Jun 2019 01:44:32 +0200 (CEST)",
                "from troi.prod.arr (mail.arr [10.99.0.5])\n\tby mx0.arrikto.com (Postfix) with ESMTP id 93A2D182004;\n\tFri, 21 Jun 2019 02:44:31 +0300 (EEST)",
                "from [10.89.50.133] (unknown [10.89.50.133])\n\tby troi.prod.arr (Postfix) with ESMTPSA id 10AB32B2;\n\tFri, 21 Jun 2019 02:44:31 +0300 (EEST)"
            ],
            "Content-Language": "en-US",
            "Content-Type": "text/plain; charset=utf-8",
            "Subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
            "In-Reply-To": "<e84d27e6-d494-547d-2151-5bc9be96626c@samsung.com>",
            "MIME-Version": "1.0",
            "Message-ID": "<8e969352-27d2-1a61-d545-0acf37c65af4@arrikto.com>",
            "Precedence": "list",
            "Content-Transfer-Encoding": "8bit",
            "X-BeenThere": "dev@dpdk.org",
            "X-Original-To": "patchwork@dpdk.org"
        }
    },
    {
        "id": 97418,
        "web_url": "http://patches.dpdk.org/comment/97418/",
        "msgid": "<aa302511-0f31-ae2d-b2cd-f7c87573ec65@arrikto.com>",
        "date": "2019-06-22T20:26:31",
        "subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
        "submitter": {
            "id": 1339,
            "url": "http://patches.dpdk.org/api/people/1339/",
            "name": "Nikos Dragazis",
            "email": "ndragazis@arrikto.com"
        },
        "content": "On 20/6/19 2:35 μ.μ., Maxime Coquelin wrote:\n> Hi Nikos,\n>\n> On 6/19/19 5:14 PM, Nikos Dragazis wrote:\n>> Hi everyone,\n>>\n>> this patch series introduces the concept of the virtio-vhost-user\n>> transport. This is actually a revised version of an earlier RFC\n>> implementation that has been proposed by Stefan Hajnoczi [1]. Though\n>> this is a great feature, it seems to have been stalled, so I’d like to\n>> restart the conversation on this and hopefully get it merged with your\n>> help. Let me give you an overview.\n>\n> Thanks for taking over the series!\n>\n> I think you are already aware of that, but it arrives too late to\n> consider it for v19.08, as the proposal deadline is over by almost 3\n> weeks.\n>\n> That said, it is good that you sent it early, so that we can work to\n> make it in for v19.11.\n\nThat's totally fine.\n\n>\n>> The virtio-vhost-user transport is a vhost-user transport implementation\n>> that is based on the virtio-vhost-user device. Its key difference with\n>> the existing transport is that it allows deploying vhost-user targets\n>> inside dedicated Storage Appliance VMs instead of host user space. In\n>> other words, it allows having guests that act as vhost-user backends for\n>> other guests.\n>>\n>> The virtio-vhost-user device implements the vhost-user control plane\n>> (master-slave communication) as follows:\n>>\n>> 1. it parses the vhost-user messages from the vhost-user unix domain\n>>     socket and forwards them to the slave guest through virtqueues\n>>\n>> 2. it maps the vhost memory regions in QEMU’s process address space and\n>>     exposes them to the slave guest as a RAM-backed PCI MMIO region\n>>\n>> 3. it hooks up doorbells to the callfds. The slave guest can use these\n>>     doorbells to interrupt the master guest driver\n>>\n>> The device code has not yet been merged into upstream QEMU, but this is\n>> definitely the end goal.\n>\n> Could you provide a pointer to the QEMU series, and instructions to test\n> this new device?\n\nOf course. Please have a look at the following step-by-step guide:\n\nhttps://github.com/ndragazis/ndragazis.github.io/blob/master/dpdk-vhost-vvu-demo.md\n\nIf you face any problems or you find that something breaks (I hope not\n:) ) please let me know. I haven't done thorough testing so I may have\nmissed something.  Please, also bear in mind that the device code is not\nfinished. There are still some things that need to be done.\n\n>\n>> The current state is that we are awaiting for\n>> the approval of the virtio spec.\n>\n> Ditto, a link to the spec patches would be useful.\n\nYou can find the patches here:\n\nhttps://lists.oasis-open.org/archives/virtio-dev/201905/msg00022.html\n\nand an HTML version is available here:\n\nhttps://ndragazis.github.io/virtio-v1.1-wd02.html#x1-41000011\n\n>\n>> I have Cced Darek from the SPDK community who has helped me a lot by\n>> reviewing this series. Note that any device type could be implemented\n>> over this new transport. So, adding the virtio-vhost-user transport in\n>> DPDK would allow using it from SPDK as well.\n>>\n>> Getting into the code internals, this patch series makes the following\n>> changes:\n>>\n>> 1. introduce a generic interface for the transport-specific operations.\n>>     Each of the two available transports, the pre-existing AF_UNIX\n>>     transport and the virtio-vhost-user transport, is going to implement\n>>     this interface. The AF_UNIX-specific code has been extracted from the\n>>     core vhost-user code and is now part of the AF_UNIX transport\n>>     implementation in trans_af_unix.c.\n>>\n>> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user\n>>     transport requires a driver for the virtio-vhost-user devices. The\n>>     driver along with the transport implementation have been packed into\n>>     a separate library in `drivers/virtio_vhost_user/`. The necessary\n>>     virtio-pci code has been copied from `drivers/net/virtio/`. Some\n>>     additional changes have been made so that the driver can utilize the\n>>     additional resources of the virtio-vhost-user device.\n>>\n>> 3. update librte_vhost public API to enable choosing transport for each\n>>     new vhost device. Extend the vhost net driver and vhost-scsi example\n>>     application to export this new API to the end user.\n>>\n>> The primary changes I did to Stefan’s RFC implementation are the\n>> following:\n>>\n>> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy\n>>     live migration relies on the userfault fd mechanism, which cannot be\n>>     supported by virtio-vhost-user.\n>>\n>> 2. moved setup of the log memory region into trans_af_unix.c. Setting up\n>>     the log memory region involves mapping/unmapping guest memory. This\n>>     is an AF_UNIX transport-specific operation.\n>>\n>> 3. introduced a vhost transport operation for\n>>     process_slave_message_reply()\n>>\n>> 4. moved the virtio-vhost-user transport/driver into a separate library\n>>     in `drivers/virtio_vhost_user/`. This required making vhost.h and\n>>     vhost_user.h part of librte_vhost public API and exporting some\n>>     private symbols via the version script. This looks better to me that\n>>     just moving the entire librte_vhost into `drivers/`. I am not sure if\n>>     this is the most appropriate solution. I am looking forward to your\n>>     suggestions on this.\n>\n> I'm not sure this is the right place to put it.\n\nOkay. Is there something specific that you think that doesn't fit\nnicely? Do you have something else in mind?\n\n>\n>> 5. made use of the virtio PCI capabilities for the additional device\n>>     resources (doorbells, shared memory). This required changes in\n>>     virtio_pci.c and trans_virtio_vhost_user.c.\n>>\n>> 6. [minor] changed some commit headlines to comply with\n>>     check-git-log.sh.\n>>\n>> Please, have a look and let me know about your thoughts. Any\n>> reviews/pointers/suggestions are welcome.\n>\n> Maxime",
        "headers": {
            "List-Id": "DPDK patches and discussions <dev.dpdk.org>",
            "From": "Nikos Dragazis <ndragazis@arrikto.com>",
            "List-Help": "<mailto:dev-request@dpdk.org?subject=help>",
            "Date": "Sat, 22 Jun 2019 23:26:31 +0300",
            "X-Mailman-Version": "2.1.15",
            "Delivered-To": "patchwork@dpdk.org",
            "List-Archive": "<http://mails.dpdk.org/archives/dev/>",
            "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n\t<mailto:dev-request@dpdk.org?subject=subscribe>",
            "Cc": "dev@dpdk.org, Tiwei Bie <tiwei.bie@intel.com>,\n\tZhihong Wang <zhihong.wang@intel.com>, Stefan Hajnoczi\n\t<stefanha@redhat.com>, Wei Wang <wei.w.wang@intel.com>,\n\tStojaczyk Dariusz <dariusz.stojaczyk@intel.com>,\n\tVangelis Koukis <vkoukis@arrikto.com>",
            "To": "Maxime Coquelin <maxime.coquelin@redhat.com>",
            "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101\n\tThunderbird/60.7.1",
            "References": "<1560957293-17294-1-git-send-email-ndragazis@arrikto.com>\n\t<d9a8eb71-b417-342b-7afb-5063b807cafb@redhat.com>",
            "Sender": "\"dev\" <dev-bounces@dpdk.org>",
            "Return-Path": "<dev-bounces@dpdk.org>",
            "Errors-To": "dev-bounces@dpdk.org",
            "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n\t<mailto:dev-request@dpdk.org?subject=unsubscribe>",
            "List-Post": "<mailto:dev@dpdk.org>",
            "Received": [
                "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 37A711C398;\n\tSat, 22 Jun 2019 22:26:35 +0200 (CEST)",
                "from mx0.arrikto.com (mx0.arrikto.com [212.71.252.59])\n\tby dpdk.org (Postfix) with ESMTP id 71EFB1C390\n\tfor <dev@dpdk.org>; Sat, 22 Jun 2019 22:26:33 +0200 (CEST)",
                "from troi.prod.arr (mail.arr [10.99.0.5])\n\tby mx0.arrikto.com (Postfix) with ESMTP id CA032182004;\n\tSat, 22 Jun 2019 23:26:32 +0300 (EEST)",
                "from [10.89.50.133] (unknown [10.89.50.133])\n\tby troi.prod.arr (Postfix) with ESMTPSA id 52E8860;\n\tSat, 22 Jun 2019 23:26:32 +0300 (EEST)"
            ],
            "Content-Language": "en-US",
            "Content-Type": "text/plain; charset=utf-8",
            "Subject": "Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport",
            "In-Reply-To": "<d9a8eb71-b417-342b-7afb-5063b807cafb@redhat.com>",
            "MIME-Version": "1.0",
            "Message-ID": "<aa302511-0f31-ae2d-b2cd-f7c87573ec65@arrikto.com>",
            "Precedence": "list",
            "Content-Transfer-Encoding": "8bit",
            "X-BeenThere": "dev@dpdk.org",
            "X-Original-To": "patchwork@dpdk.org"
        }
    }
]