From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 952B725B3 for ; Thu, 1 Feb 2018 15:46:16 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1FED320AEF; Thu, 1 Feb 2018 09:46:16 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 01 Feb 2018 09:46:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux.org; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=52HuIkDLFH2OdPYKHg2OqEKCFaM2r5HXEiqXPxNrBzw=; b=LHUwlNBY jjlRUABXr+PpcovG6qEWzp7btnugCe8eyLAv/bNzMxEYFqrYBxNddvP6xUHmDT4l P67rLgMPDFRoI3SvO/kcuChx3eIYTzLFdcLsi499JNLt1L1qsX1BAnqstoRWEAy6 QxpYUct4xRZsaMKHX3a+BgoiCKXbACVGnqZbTjmF1eHLSnzLNlMZ9EKaweLHcjld ygHqPMNwV9L7Gy5ne89MUwwr45tNxV9OUQDN8y3K9UUjAHQ08xndGnKtAMurP9Ey otyi8B0DJoig/Jy4NBCtt5JaO58UQ5+a35r7G3g4RudA/VVTBIwds41QMsOveVyM k1UQkKCt6t9CdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=52HuIkDLFH2OdPYKHg2OqEKCFaM2r 5HXEiqXPxNrBzw=; b=morROI1LHv6HkH+tzWkPSjVaGduKROvpJoxFz2Ejpup6F 68phtDUZEA9oRV9NGjDe0+/83GmrJlEBK4wW5gpOWmh1eNAYac+HH2YuQg+e8x63 XJs3oE+aI5BkRqsbcuc6qolod+XcHUa285OT/Uj0Hbk33Dh78G66M9YPRimdXMaa 1oTYWOmfqWR7Xe1mCaHj+HudWSeS6RFxmvup3kdZ9OTW6KHspasSlZnAk0R4YyUz IZGaOVaAwrSC4QUk+PDFV8thiQLGidifPpH+pZQi6jQNnNo+hN8vl+wO7vZPj8eM e69f06ErUuIyNyrbBM0FrV3huVHP3VyDkCo4UY/YA== X-ME-Sender: Received: from yliu-mob (unknown [115.150.27.200]) by mail.messagingengine.com (Postfix) with ESMTPA id F22CC7E5CB; Thu, 1 Feb 2018 09:46:14 -0500 (EST) Date: Thu, 1 Feb 2018 22:46:11 +0800 From: Yuanhan Liu To: Stefan Hajnoczi Cc: dev@dpdk.org, Maxime Coquelin Message-ID: <20180201144611.GP29540@yliu-mob> References: <20180131174651.6386-1-stefanha@redhat.com> <20180131174651.6386-2-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180131174651.6386-2-stefanha@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [PATCH 1/2] vhost: add flag for built-in virtio_net.c driver 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, 01 Feb 2018 14:46:16 -0000 Hi Stefan, On Wed, Jan 31, 2018 at 05:46:50PM +0000, Stefan Hajnoczi wrote: > The librte_vhost API is used in two ways: > 1. As a vhost net device backend via rte_vhost_enqueue/dequeue_burst(). This is how DPDK vhost-user firstly implemented. > 2. As a library for implementing vhost device backends. This is how DPDK vhost-use extended later, and vhost-user scsi is the first one being added. > There is no distinction between the two at the API level or in the > librte_vhost implementation. For example, device state is kept in > "struct virtio_net" regardless of whether this is actually a net device > backend or whether the built-in virtio_net.c driver is in use. Indeed. virtio_net should be renamed to "vhost_dev" or something like this. It's part of something un-finished in the last vhost-user extension refactoring. > > The virtio_net.c driver should be a librte_vhost API client just like > the vhost-scsi code and have no special access to vhost.h internals. > Unfortunately, fixing this requires significant librte_vhost API > changes. The way I thought was to move the virtio_net.c completely to vhost pmd (drivers/net/vhost). And let vhost-user just be a generic lib without any device specific stuff. Unfortunately, it can not be done recently, as there are still a lot of applications using rte_vhost_enqueue/dequeue_burst directly, for example, OVS. > This patch takes a different approach: keep the librte_vhost API > unchanged but track whether the built-in virtio_net.c driver is in use. > See the next patch for a bug fix that requires knowledge of whether > virtio_net.c is in use. LGTM. Thanks. --yliu