From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by dpdk.org (Postfix) with ESMTP id 4A64E56A3 for ; Tue, 30 Apr 2019 10:38:07 +0200 (CEST) Received: by mail-ot1-f65.google.com with SMTP id d24so11145156otl.11 for ; Tue, 30 Apr 2019 01:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0FiN9djKzUaJXYHrLQZi6mhzaUzmcCuMo+lL0Xw8ZxM=; b=OZjJtfJbTQbun1m++YFB2V4sWOEBH0U0SG1ZlvHPLqg27UHgAS2oRgtK+HXbn1WA2i zjXeComPNozCuXT5kF67mC44pXGdVLSyk9O0zytV+dsGNWeggFl8BFmrcIqEmDEud6pU EBGy7J6JuTh2doQxCuXbqVUG99k1RhYVP2gPmMXbnFDGnnA3Iw+9y4cYF2CLGErchYJc xLqz/Y9EJ+3kZj1XT3v3QK3l08eCgBwqpeDYIQ7E3gETdFyT7WdUfLthTd5hAM1SxoO+ k5zKIdRR9mVDLW+omzY/0aZAAKpe2vftHs/3j1bsWLDJsid+26xutZtxWFdXnQpcLsGg JBGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0FiN9djKzUaJXYHrLQZi6mhzaUzmcCuMo+lL0Xw8ZxM=; b=So1Zg194yD7u0NdVEU7xE7J8QyFCN4X5YCk7Kd3JEo5gfdVbmB1QEWqJsDkfr5M+cj 4cbApEiCtV1buYLlZ2GaLhSczSKx+/QVVFwWd/1UseCKR+lZxZuX4mOtYCQcj7whjaKJ MWGGbykx42HDRlxEFCCeZCZndDYbjgHilv73TGiP25dy2FTldzzjOKNbdWSL6DmbBH2b 7alCxxB/8BsmRdxEOQdAbRZyOCuep3yTdI3U1DROJtJn5mG5aARxMnx6wZ+/1H89EXbY QCr+Rq5xGm7x7D5OoHGVTxab4y6vP881CA+TKdiE/agO6w1IEkKtLqQkHFjQ3AZJotEn Zqkw== X-Gm-Message-State: APjAAAUlYrWM2tZercq/FdyDL+ovN6/WbrTs1bufb/KV6ym21ZvstLu/ RrbQ2aUuc3eKfULNYsr+u+DF+fdsAskyEbwm9dk= X-Google-Smtp-Source: APXvYqw+QtURnUDwO+SZc6LBWAW6AE1+f41D6fdjQrYfo4JnELLutWNxfBIRzZtA8vNaIsV+e3LADAUpZ/Ndr3WfOVw= X-Received: by 2002:a9d:7d0e:: with SMTP id v14mr42041429otn.225.1556613486418; Tue, 30 Apr 2019 01:38:06 -0700 (PDT) MIME-Version: 1.0 References: <1556190633-8099-1-git-send-email-chuckylinchuckylin@gmail.com> <1556271621-8594-1-git-send-email-chuckylinchuckylin@gmail.com> <20190428111748.GA16470@___> <20190429105425.GA12868@___> In-Reply-To: <20190429105425.GA12868@___> From: lin li Date: Tue, 30 Apr 2019 16:37:58 +0800 Message-ID: To: Tiwei Bie Cc: "maxime.coquelin@redhat.com" , "zhihong.wang@intel.com" , "dev@dpdk.org" , "dariusz.stojaczyk@intel.com" , "changpeng.liu@intel.com" , "james.r.harris@intel.com" , lilin24 , Ni Xun , Zhang Yu , "mst@redhat.com" , xieyongji@baidu.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature 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: Tue, 30 Apr 2019 08:38:07 -0000 Tiwei Bie =E4=BA=8E2019=E5=B9=B44=E6=9C=8829=E6=97=A5= =E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=886:55=E5=86=99=E9=81=93=EF=BC=9A > > On Mon, Apr 29, 2019 at 12:07:05PM +0800, lin li wrote: > > Tiwei Bie =E4=BA=8E2019=E5=B9=B44=E6=9C=8828=E6= =97=A5=E5=91=A8=E6=97=A5 =E4=B8=8B=E5=8D=887:18=E5=86=99=E9=81=93=EF=BC=9A > > > On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote: > [...] > > > > @@ -98,12 +102,26 @@ struct rte_vhost_memory { > > > > struct rte_vhost_mem_region regions[]; > > > > }; > > > > > > > > +typedef struct VhostUserInflightEntry { > > > > + uint8_t inflight; > > > > +} VhostUserInflightEntry; > > > > + > > > > +typedef struct VhostInflightInfo { > > > > + uint16_t version; > > > > + uint16_t last_inflight_io; > > > > + uint16_t used_idx; > > > > + VhostUserInflightEntry desc[0]; > > > > +} VhostInflightInfo; > > > > > > Is there any details on above structure? Why does it not match > > > QueueRegionSplit or QueueRegionPacked structures described in > > > qemu/docs/interop/vhost-user.txt? > > > > Qemu have its vhost-user backend=EF=BC=8C > > Do you mean contrib/libvhost-user in QEMU? > > > qemu did the submission of IO in it. > > What does this mean? > > > The implementation of dpdk is more general. It is just to mark inflight= entry. > > Based on the discussion in below threads: > > https://patchwork.kernel.org/patch/10753893/ > https://patchwork.kernel.org/patch/10817735/ > > IIUC, above structure is the extra buffer allocated by slave to > store the information of inflight descriptors and share with master > for persistent. All vhost-user backends' implementation should > follow the vhost-user protocol (including the format of above > structure) defined in qemu/docs/interop/vhost-user.txt. Right? Yes you're right. I've confirmed with QEMU that these data structures are consistent with qemu. It will be consistent with QEMU in the next version. > > > The submission of inflight entry is handle over to different backends. > > They have their own ways to handle it, such as spdk. > > So there are some differences in data structure. > > > > > > [...] > > > > +static int > > > > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg = *msg, > > > > + int main_fd __rte_unused) > > > > +{ > > > > + int fd, i; > > > > + uint64_t mmap_size, mmap_offset; > > > > + uint16_t num_queues, queue_size; > > > > + uint32_t pervq_inflight_size; > > > > + void *rc; > > > > + struct vhost_virtqueue *vq; > > > > + struct virtio_net *dev =3D *pdev; > > > > + > > > > + fd =3D msg->fds[0]; > > > > + if (msg->size !=3D sizeof(msg->payload.inflight) || fd < 0) { > > > > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd m= essage size is %d,fd is %d\n", > > > > + msg->size, fd); > > > > + return -1; > > > > > > Ditto. > > > > > > > + } > > > > + > > > > + mmap_size =3D msg->payload.inflight.mmap_size; > > > > + mmap_offset =3D msg->payload.inflight.mmap_offset; > > > > + num_queues =3D msg->payload.inflight.num_queues; > > > > + queue_size =3D msg->payload.inflight.queue_size; > > > > + pervq_inflight_size =3D get_pervq_shm_size(queue_size); > > > > + > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd mmap_size: %lu\n", mmap_size); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd num_queues: %u\n", num_queues); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd queue_size: %u\n", queue_size); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd fd: %d\n", fd); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd pervq_inflight_size: %d\n", > > > > + pervq_inflight_size); > > > > + > > > > + if (dev->inflight_info.addr) > > > > + munmap(dev->inflight_info.addr, dev->inflight_info.si= ze); > > > > + > > > > + rc =3D mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED, > > > > + fd, mmap_offset); > > > > > > Why call it rc? Maybe addr is a better name? > > > > In some scenarios, shared memory is reallocated or resized by qemu, so > > again mmap is needed. > > In which case the shared memory will be reallocated or resized by QEMU? QEMU replies that it needs to copy inflight share memory data when live migration occurs. If the size of inflight buffer on two machines is not the same, QEMU will reallocate memory according to the old inflight buffer size. > > > > > > > > > > + if (rc =3D=3D MAP_FAILED) { > > > > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memo= ry.\n"); > > > > + return -1; > > > > > > Should always return RTE_VHOST_MSG_RESULT_* in > > > message handler. > > > > > > > + } > > > > + > > > > + if (dev->inflight_info.fd) > > > > + close(dev->inflight_info.fd); > > > > + > > > > + dev->inflight_info.fd =3D fd; > > > > + dev->inflight_info.addr =3D rc; > > > > + dev->inflight_info.size =3D mmap_size; > > > > + > > > > + for (i =3D 0; i < num_queues; i++) { > > > > + vq =3D dev->virtqueue[i]; > > > > + vq->inflight =3D (VhostInflightInfo *)rc; > > > > + rc =3D (void *)((char *)rc + pervq_inflight_size); > > > > + } > > > > + > > > > + return RTE_VHOST_MSG_RESULT_OK; > > > > +} > [...] > > > > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost= _user.h > > > > index 2a650fe4b..35f969b1b 100644 > > > > --- a/lib/librte_vhost/vhost_user.h > > > > +++ b/lib/librte_vhost/vhost_user.h > > > > @@ -23,7 +23,8 @@ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_CRYPTO_SESSION) | \ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_SLAVE_SEND_FD) | \ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_HOST_NOTIFIER) | \ > > > > - (1ULL << VHOST_USER_PROTOCOL= _F_PAGEFAULT)) > > > > + (1ULL << VHOST_USER_PROTOCOL_= F_PAGEFAULT) | \ > > > > + (1ULL << VHOST_USER_PROTOCOL_= F_INFLIGHT_SHMFD)) > > > > > > It will advertise this feature for builtin net and crypto > > > backends. It's probably not what you intended. > > > > > > > Indeed, this feature is mainly used for spdk-like backends. You mean > > this function is disabled by default=EF=BC=9F > > External backends should use rte_vhost_driver_set_protocol_features() > to advertise the protocol features they support. Thanks=EF=BC=8CIt will be modified in the next version. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id F093EA0679 for ; Tue, 30 Apr 2019 10:38:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 170DB5B38; Tue, 30 Apr 2019 10:38:08 +0200 (CEST) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by dpdk.org (Postfix) with ESMTP id 4A64E56A3 for ; Tue, 30 Apr 2019 10:38:07 +0200 (CEST) Received: by mail-ot1-f65.google.com with SMTP id d24so11145156otl.11 for ; Tue, 30 Apr 2019 01:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0FiN9djKzUaJXYHrLQZi6mhzaUzmcCuMo+lL0Xw8ZxM=; b=OZjJtfJbTQbun1m++YFB2V4sWOEBH0U0SG1ZlvHPLqg27UHgAS2oRgtK+HXbn1WA2i zjXeComPNozCuXT5kF67mC44pXGdVLSyk9O0zytV+dsGNWeggFl8BFmrcIqEmDEud6pU EBGy7J6JuTh2doQxCuXbqVUG99k1RhYVP2gPmMXbnFDGnnA3Iw+9y4cYF2CLGErchYJc xLqz/Y9EJ+3kZj1XT3v3QK3l08eCgBwqpeDYIQ7E3gETdFyT7WdUfLthTd5hAM1SxoO+ k5zKIdRR9mVDLW+omzY/0aZAAKpe2vftHs/3j1bsWLDJsid+26xutZtxWFdXnQpcLsGg JBGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0FiN9djKzUaJXYHrLQZi6mhzaUzmcCuMo+lL0Xw8ZxM=; b=So1Zg194yD7u0NdVEU7xE7J8QyFCN4X5YCk7Kd3JEo5gfdVbmB1QEWqJsDkfr5M+cj 4cbApEiCtV1buYLlZ2GaLhSczSKx+/QVVFwWd/1UseCKR+lZxZuX4mOtYCQcj7whjaKJ MWGGbykx42HDRlxEFCCeZCZndDYbjgHilv73TGiP25dy2FTldzzjOKNbdWSL6DmbBH2b 7alCxxB/8BsmRdxEOQdAbRZyOCuep3yTdI3U1DROJtJn5mG5aARxMnx6wZ+/1H89EXbY QCr+Rq5xGm7x7D5OoHGVTxab4y6vP881CA+TKdiE/agO6w1IEkKtLqQkHFjQ3AZJotEn Zqkw== X-Gm-Message-State: APjAAAUlYrWM2tZercq/FdyDL+ovN6/WbrTs1bufb/KV6ym21ZvstLu/ RrbQ2aUuc3eKfULNYsr+u+DF+fdsAskyEbwm9dk= X-Google-Smtp-Source: APXvYqw+QtURnUDwO+SZc6LBWAW6AE1+f41D6fdjQrYfo4JnELLutWNxfBIRzZtA8vNaIsV+e3LADAUpZ/Ndr3WfOVw= X-Received: by 2002:a9d:7d0e:: with SMTP id v14mr42041429otn.225.1556613486418; Tue, 30 Apr 2019 01:38:06 -0700 (PDT) MIME-Version: 1.0 References: <1556190633-8099-1-git-send-email-chuckylinchuckylin@gmail.com> <1556271621-8594-1-git-send-email-chuckylinchuckylin@gmail.com> <20190428111748.GA16470@___> <20190429105425.GA12868@___> In-Reply-To: <20190429105425.GA12868@___> From: lin li Date: Tue, 30 Apr 2019 16:37:58 +0800 Message-ID: To: Tiwei Bie Cc: "maxime.coquelin@redhat.com" , "zhihong.wang@intel.com" , "dev@dpdk.org" , "dariusz.stojaczyk@intel.com" , "changpeng.liu@intel.com" , "james.r.harris@intel.com" , lilin24 , Ni Xun , Zhang Yu , "mst@redhat.com" , xieyongji@baidu.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190430083758.yZ14APo4ZqqloUosYjllIrzZekq64kSIWfuTrxXS9VU@z> Tiwei Bie =E4=BA=8E2019=E5=B9=B44=E6=9C=8829=E6=97=A5= =E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=886:55=E5=86=99=E9=81=93=EF=BC=9A > > On Mon, Apr 29, 2019 at 12:07:05PM +0800, lin li wrote: > > Tiwei Bie =E4=BA=8E2019=E5=B9=B44=E6=9C=8828=E6= =97=A5=E5=91=A8=E6=97=A5 =E4=B8=8B=E5=8D=887:18=E5=86=99=E9=81=93=EF=BC=9A > > > On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote: > [...] > > > > @@ -98,12 +102,26 @@ struct rte_vhost_memory { > > > > struct rte_vhost_mem_region regions[]; > > > > }; > > > > > > > > +typedef struct VhostUserInflightEntry { > > > > + uint8_t inflight; > > > > +} VhostUserInflightEntry; > > > > + > > > > +typedef struct VhostInflightInfo { > > > > + uint16_t version; > > > > + uint16_t last_inflight_io; > > > > + uint16_t used_idx; > > > > + VhostUserInflightEntry desc[0]; > > > > +} VhostInflightInfo; > > > > > > Is there any details on above structure? Why does it not match > > > QueueRegionSplit or QueueRegionPacked structures described in > > > qemu/docs/interop/vhost-user.txt? > > > > Qemu have its vhost-user backend=EF=BC=8C > > Do you mean contrib/libvhost-user in QEMU? > > > qemu did the submission of IO in it. > > What does this mean? > > > The implementation of dpdk is more general. It is just to mark inflight= entry. > > Based on the discussion in below threads: > > https://patchwork.kernel.org/patch/10753893/ > https://patchwork.kernel.org/patch/10817735/ > > IIUC, above structure is the extra buffer allocated by slave to > store the information of inflight descriptors and share with master > for persistent. All vhost-user backends' implementation should > follow the vhost-user protocol (including the format of above > structure) defined in qemu/docs/interop/vhost-user.txt. Right? Yes you're right. I've confirmed with QEMU that these data structures are consistent with qemu. It will be consistent with QEMU in the next version. > > > The submission of inflight entry is handle over to different backends. > > They have their own ways to handle it, such as spdk. > > So there are some differences in data structure. > > > > > > [...] > > > > +static int > > > > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg = *msg, > > > > + int main_fd __rte_unused) > > > > +{ > > > > + int fd, i; > > > > + uint64_t mmap_size, mmap_offset; > > > > + uint16_t num_queues, queue_size; > > > > + uint32_t pervq_inflight_size; > > > > + void *rc; > > > > + struct vhost_virtqueue *vq; > > > > + struct virtio_net *dev =3D *pdev; > > > > + > > > > + fd =3D msg->fds[0]; > > > > + if (msg->size !=3D sizeof(msg->payload.inflight) || fd < 0) { > > > > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd m= essage size is %d,fd is %d\n", > > > > + msg->size, fd); > > > > + return -1; > > > > > > Ditto. > > > > > > > + } > > > > + > > > > + mmap_size =3D msg->payload.inflight.mmap_size; > > > > + mmap_offset =3D msg->payload.inflight.mmap_offset; > > > > + num_queues =3D msg->payload.inflight.num_queues; > > > > + queue_size =3D msg->payload.inflight.queue_size; > > > > + pervq_inflight_size =3D get_pervq_shm_size(queue_size); > > > > + > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd mmap_size: %lu\n", mmap_size); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd num_queues: %u\n", num_queues); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd queue_size: %u\n", queue_size); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd fd: %d\n", fd); > > > > + RTE_LOG(INFO, VHOST_CONFIG, > > > > + "set_inflight_fd pervq_inflight_size: %d\n", > > > > + pervq_inflight_size); > > > > + > > > > + if (dev->inflight_info.addr) > > > > + munmap(dev->inflight_info.addr, dev->inflight_info.si= ze); > > > > + > > > > + rc =3D mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED, > > > > + fd, mmap_offset); > > > > > > Why call it rc? Maybe addr is a better name? > > > > In some scenarios, shared memory is reallocated or resized by qemu, so > > again mmap is needed. > > In which case the shared memory will be reallocated or resized by QEMU? QEMU replies that it needs to copy inflight share memory data when live migration occurs. If the size of inflight buffer on two machines is not the same, QEMU will reallocate memory according to the old inflight buffer size. > > > > > > > > > > + if (rc =3D=3D MAP_FAILED) { > > > > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memo= ry.\n"); > > > > + return -1; > > > > > > Should always return RTE_VHOST_MSG_RESULT_* in > > > message handler. > > > > > > > + } > > > > + > > > > + if (dev->inflight_info.fd) > > > > + close(dev->inflight_info.fd); > > > > + > > > > + dev->inflight_info.fd =3D fd; > > > > + dev->inflight_info.addr =3D rc; > > > > + dev->inflight_info.size =3D mmap_size; > > > > + > > > > + for (i =3D 0; i < num_queues; i++) { > > > > + vq =3D dev->virtqueue[i]; > > > > + vq->inflight =3D (VhostInflightInfo *)rc; > > > > + rc =3D (void *)((char *)rc + pervq_inflight_size); > > > > + } > > > > + > > > > + return RTE_VHOST_MSG_RESULT_OK; > > > > +} > [...] > > > > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost= _user.h > > > > index 2a650fe4b..35f969b1b 100644 > > > > --- a/lib/librte_vhost/vhost_user.h > > > > +++ b/lib/librte_vhost/vhost_user.h > > > > @@ -23,7 +23,8 @@ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_CRYPTO_SESSION) | \ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_SLAVE_SEND_FD) | \ > > > > (1ULL << VHOST_USER_PROTOCOL= _F_HOST_NOTIFIER) | \ > > > > - (1ULL << VHOST_USER_PROTOCOL= _F_PAGEFAULT)) > > > > + (1ULL << VHOST_USER_PROTOCOL_= F_PAGEFAULT) | \ > > > > + (1ULL << VHOST_USER_PROTOCOL_= F_INFLIGHT_SHMFD)) > > > > > > It will advertise this feature for builtin net and crypto > > > backends. It's probably not what you intended. > > > > > > > Indeed, this feature is mainly used for spdk-like backends. You mean > > this function is disabled by default=EF=BC=9F > > External backends should use rte_vhost_driver_set_protocol_features() > to advertise the protocol features they support. Thanks=EF=BC=8CIt will be modified in the next version.