From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 98DF5A0A04; Fri, 15 Jan 2021 15:19:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 657B5141116; Fri, 15 Jan 2021 15:19:53 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 45A15141115 for ; Fri, 15 Jan 2021 15:19:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610720391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X+uAjxZtY9fjFWjvOdd0eUknXgkkyQSSyVjPXdqUthY=; b=fm7mt2f3QDKZlAg5XnsrQUQG52kl15dokPXXNVKQl7+9OwrPiP070WrWRCwr8r0nQ5JFJ3 hNMpji2XE0ipZbvGxi0qnZtvngM3V5Cns888EglkK9eTktOFB4pR7cnXEgyRySjdD6IVKo I5vB+oGIYyd0489PnEcZzcIHiK45zNI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-593-QKVrvY2mO7ivUy0WF7FdUQ-1; Fri, 15 Jan 2021 09:19:46 -0500 X-MC-Unique: QKVrvY2mO7ivUy0WF7FdUQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 18B20100C660; Fri, 15 Jan 2021 14:19:45 +0000 (UTC) Received: from [10.36.110.24] (unknown [10.36.110.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 866BB5D74F; Fri, 15 Jan 2021 14:19:43 +0000 (UTC) To: Adrian Moreno , "Xia, Chenbo" , "dev@dpdk.org" , "olivier.matz@6wind.com" , "david.marchand@redhat.com" References: <20201220211405.313012-1-maxime.coquelin@redhat.com> <20201220211405.313012-26-maxime.coquelin@redhat.com> <6b3ee0bc-1e26-0b48-6f84-90c4948e228b@redhat.com> From: Maxime Coquelin Message-ID: <933531fd-7ab0-d3a2-23a9-046767d46077@redhat.com> Date: Fri, 15 Jan 2021 15:19:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6b3ee0bc-1e26-0b48-6f84-90c4948e228b@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 25/40] net/virtio: add Virtio-user features ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On 1/13/21 2:43 PM, Adrian Moreno wrote: > Hi Chenbo > > On 1/6/21 12:54 PM, Xia, Chenbo wrote: >> Hi Maxime, >> >>> -----Original Message----- >>> From: Maxime Coquelin >>> Sent: Monday, December 21, 2020 5:14 AM >>> To: dev@dpdk.org; Xia, Chenbo ; olivier.matz@6wind.com; >>> amorenoz@redhat.com; david.marchand@redhat.com >>> Cc: Maxime Coquelin >>> Subject: [PATCH 25/40] net/virtio: add Virtio-user features ops >>> >>> This patch introduce new callbacks for getting >> >> s/introduce/introduces >> >>> and setting Virtio features, and implements them >>> for the different backend types. >>> >>> Signed-off-by: Maxime Coquelin >>> --- >>> drivers/net/virtio/virtio_user/vhost.h | 2 + >>> drivers/net/virtio/virtio_user/vhost_kernel.c | 150 +++++++++--------- >>> .../net/virtio/virtio_user/vhost_kernel_tap.c | 23 +++ >>> .../net/virtio/virtio_user/vhost_kernel_tap.h | 1 + >>> drivers/net/virtio/virtio_user/vhost_user.c | 63 +++++++- >>> drivers/net/virtio/virtio_user/vhost_vdpa.c | 38 +++-- >>> .../net/virtio/virtio_user/virtio_user_dev.c | 5 +- >>> drivers/net/virtio/virtio_user_ethdev.c | 3 +- >>> 8 files changed, 188 insertions(+), 97 deletions(-) >>> >>> diff --git a/drivers/net/virtio/virtio_user/vhost.h >>> b/drivers/net/virtio/virtio_user/vhost.h >>> index 8e819ecfb8..16978e27ed 100644 >>> --- a/drivers/net/virtio/virtio_user/vhost.h >>> +++ b/drivers/net/virtio/virtio_user/vhost.h >>> @@ -102,6 +102,8 @@ struct virtio_user_dev; >>> struct virtio_user_backend_ops { >>> int (*setup)(struct virtio_user_dev *dev); >>> int (*set_owner)(struct virtio_user_dev *dev); >>> + int (*get_features)(struct virtio_user_dev *dev, uint64_t *features); >>> + int (*set_features)(struct virtio_user_dev *dev, uint64_t features); >>> int (*send_request)(struct virtio_user_dev *dev, >>> enum vhost_user_request req, >>> void *arg); >>> diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c >>> b/drivers/net/virtio/virtio_user/vhost_kernel.c >>> index b79dcad179..f44df8ef1f 100644 >>> --- a/drivers/net/virtio/virtio_user/vhost_kernel.c >>> +++ b/drivers/net/virtio/virtio_user/vhost_kernel.c >>> @@ -38,6 +38,28 @@ struct vhost_memory_kernel { >>> #define VHOST_SET_VRING_ERR _IOW(VHOST_VIRTIO, 0x22, struct vhost_vring_file) >>> #define VHOST_NET_SET_BACKEND _IOW(VHOST_VIRTIO, 0x30, struct >>> vhost_vring_file) >>> >>> +/* with below features, vhost kernel does not need to do the checksum and TSO, >>> + * these info will be passed to virtio_user through virtio net header. >>> + */ >>> +#define VHOST_KERNEL_GUEST_OFFLOADS_MASK \ >>> + ((1ULL << VIRTIO_NET_F_GUEST_CSUM) | \ >>> + (1ULL << VIRTIO_NET_F_GUEST_TSO4) | \ >>> + (1ULL << VIRTIO_NET_F_GUEST_TSO6) | \ >>> + (1ULL << VIRTIO_NET_F_GUEST_ECN) | \ >>> + (1ULL << VIRTIO_NET_F_GUEST_UFO)) >>> + >>> +/* with below features, when flows from virtio_user to vhost kernel >>> + * (1) if flows goes up through the kernel networking stack, it does not need >>> + * to verify checksum, which can save CPU cycles; >>> + * (2) if flows goes through a Linux bridge and outside from an interface >>> + * (kernel driver), checksum and TSO will be done by GSO in kernel or even >>> + * offloaded into real physical device. >>> + */ >>> +#define VHOST_KERNEL_HOST_OFFLOADS_MASK \ >>> + ((1ULL << VIRTIO_NET_F_HOST_TSO4) | \ >>> + (1ULL << VIRTIO_NET_F_HOST_TSO6) | \ >>> + (1ULL << VIRTIO_NET_F_CSUM)) >>> + >>> static uint64_t max_regions = 64; >>> >>> static void >>> @@ -77,10 +99,57 @@ vhost_kernel_set_owner(struct virtio_user_dev *dev) >>> return vhost_kernel_ioctl(dev->vhostfds[0], VHOST_SET_OWNER, NULL); >>> } >>> >>> +static int >>> +vhost_kernel_get_features(struct virtio_user_dev *dev, uint64_t *features) >>> +{ >>> + int ret; >>> + unsigned int tap_features; >>> + >>> + ret = vhost_kernel_ioctl(dev->vhostfds[0], VHOST_GET_FEATURES, features); >>> + if (ret < 0) { >>> + PMD_DRV_LOG(ERR, "Failed to get features"); >>> + return -1; >>> + } >>> + >>> + ret = tap_support_features(&tap_features); >>> + if (ret < 0) { >>> + PMD_DRV_LOG(ERR, "Failed to get TAP features)"); >> >> should delete ')' after 'features'? >> >>> + return -1; >>> + } >>> + >>> + /* with tap as the backend, all these features are supported >>> + * but not claimed by vhost-net, so we add them back when >>> + * reporting to upper layer. >>> + */ >> >> >> >>> .dma_map = vhost_vdpa_dma_map, >>> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c >>> b/drivers/net/virtio/virtio_user/virtio_user_dev.c >>> index f8e4581951..0a85d058a8 100644 >>> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c >>> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c >>> @@ -141,7 +141,7 @@ virtio_user_dev_set_features(struct virtio_user_dev *dev) >>> /* Strip VIRTIO_NET_F_CTRL_VQ, as devices do not really need to know */ >>> features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ); >>> features &= ~(1ull << VIRTIO_NET_F_STATUS); >>> - ret = dev->ops->send_request(dev, VHOST_USER_SET_FEATURES, &features); >>> + ret = dev->ops->set_features(dev, features); >> >> I noticed that virtio_user_dev_set_features is called by virtio_user_set_status. >> The former may fail but the latter will ignore the failure. So this will happen: >> setting features already failed but virtio-user still continue to do things. IMHO, >> this is not very good (similar things may happen for virtio_user_start_device). >> What do you think? >> > You're right. Although set_status(features_ok) should be followed by > get_status() to check if device has set feature_ok bit, the problem is that > set_status is called on device initialization, which would happen even when the > vhost backed is not yet connected (server-mode). Failing there would tear down > the ethdev which would make the future "hotplug" fail. Hopefully this will all > be fixed by Maxime's refactoring :) > So +1 to reconsider improving error propagation here. I agree with the idea of improving the error propagation, maybe it can be done after the series is merged as further improvements. With making server mode made blocking, it will be easier to handle. But there is still the reconnection case that could be problematic, I prefer not risking introducing more regressions for this series :). Is that OK for you? Cheers, Maxime > >> Thanks, >> Chenbo >> >>> if (ret < 0) >>> goto error; >>> PMD_DRV_LOG(INFO, "set features: %" PRIx64, features); >>> @@ -488,8 +488,7 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char >>> *path, int queues, >>> return -1; >>> } >>> >>> - if (dev->ops->send_request(dev, VHOST_USER_GET_FEATURES, >>> - &dev->device_features) < 0) { >>> + if (dev->ops->get_features(dev, &dev->device_features) < 0) { >>> PMD_INIT_LOG(ERR, "get_features failed: %s", >>> strerror(errno)); >>> return -1; >>> diff --git a/drivers/net/virtio/virtio_user_ethdev.c >>> b/drivers/net/virtio/virtio_user_ethdev.c >>> index 283f5c7a36..4d2635c8aa 100644 >>> --- a/drivers/net/virtio/virtio_user_ethdev.c >>> +++ b/drivers/net/virtio/virtio_user_ethdev.c >>> @@ -85,8 +85,7 @@ virtio_user_server_reconnect(struct virtio_user_dev *dev) >>> >>> virtio_set_status(hw, VIRTIO_CONFIG_STATUS_DRIVER); >>> >>> - if (dev->ops->send_request(dev, VHOST_USER_GET_FEATURES, >>> - &dev->device_features) < 0) { >>> + if (dev->ops->get_features(dev, &dev->device_features) < 0) { >>> PMD_INIT_LOG(ERR, "get_features failed: %s", >>> strerror(errno)); >>> return -1; >>> -- >>> 2.29.2 >> >