From patchwork Thu Oct 17 15:00:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Maximets X-Patchwork-Id: 61409 X-Patchwork-Delegate: maxime.coquelin@redhat.com Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 67B411E976; Thu, 17 Oct 2019 17:00:27 +0200 (CEST) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by dpdk.org (Postfix) with ESMTP id A050D1E96A for ; Thu, 17 Oct 2019 17:00:26 +0200 (CEST) Received: from localhost.localdomain (238.210.broadband10.iol.cz [90.177.210.238]) (Authenticated sender: i.maximets@ovn.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 40595240005; Thu, 17 Oct 2019 15:00:25 +0000 (UTC) From: Ilya Maximets To: dev@dpdk.org, Maxime Coquelin Cc: Flavio Leitner , David Marchand , Tiwei Bie , Ilya Maximets Date: Thu, 17 Oct 2019 17:00:19 +0200 Message-Id: <20191017150019.19191-1-i.maximets@ovn.org> X-Mailer: git-send-email 2.17.1 Subject: [dpdk-dev] [PATCH] vhost: disable host TSO for linear buffers without extbuf 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" If linear buffers requested and external buffers are not, vhost will not be able to receive any buffer that doesn't fit in a single mbuf. Moreover, if such a buffer will appear in a vring it will never be dequeued and the whole vring will become dead breaking the network connection. Disable segmentation offloading from the host side to avoid having such a big buffers. Cc: Flavio Leitner Fixes: 5005bcda7123 ("vhost: add support for large buffers") Signed-off-by: Ilya Maximets Reviewed-by: Maxime Coquelin --- There is still an assumption that users are sane enough to have MTU sized mbufs in a memory pool and that guest will not change MTU to higher values. We, probably, still need to have a check on dequeue path and drop oversized buffers in case of linear buffers to avoid stuck of the virtqueue. Or simply drop support of '+linear -extbuf' case. Note: Only compile tested due to lack of HW. lib/librte_vhost/socket.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c index 2d3d20804..1036eaad4 100644 --- a/lib/librte_vhost/socket.c +++ b/lib/librte_vhost/socket.c @@ -933,6 +933,24 @@ rte_vhost_driver_register(const char *path, uint64_t flags) ~(1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT); } + /* + * We'll not be able to receive a buffer from guest in linear mode + * without external buffer if it will not fit in a single mbuf, which is + * likely if segmentation offloading enabled. + */ + if (vsocket->linearbuf && !vsocket->extbuf) { + uint64_t seg_offload_features = + (1ULL << VIRTIO_NET_F_HOST_TSO4) | + (1ULL << VIRTIO_NET_F_HOST_TSO6) | + (1ULL << VIRTIO_NET_F_HOST_UFO); + + RTE_LOG(INFO, VHOST_CONFIG, + "Linear buffers requested without external buffers, " + "disabling host segmentation offloading support\n"); + vsocket->supported_features &= ~seg_offload_features; + vsocket->features &= ~seg_offload_features; + } + if (!(flags & RTE_VHOST_USER_IOMMU_SUPPORT)) { vsocket->supported_features &= ~(1ULL << VIRTIO_F_IOMMU_PLATFORM); vsocket->features &= ~(1ULL << VIRTIO_F_IOMMU_PLATFORM);