From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8911AA09EF; Mon, 21 Dec 2020 11:59:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 80DE0CAAE; Mon, 21 Dec 2020 11:59:01 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 223EFCA5C for ; Mon, 21 Dec 2020 11:58:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608548337; 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=0xMLJECZTFSkY/58ujHDW3c0rUZ70+2rGuj1ncX8glk=; b=K5cpo0JMFeEGd5LTr+VqqtXASws+WueXZt1k7YAGut/Cq1vd0QtxpLSBNjmHsb+W7nzRQo afWSo7krk0pTYuzXOWN1PJF9E+w94PRbJ9Isdk//Z6ZCq7Sjmu7xhonOrFyPyAwem/5AC1 ztbhIjeeWADfzw1Wgu6hHRcQEuRb8rs= 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-198-q1mUze6SP9KhSAY1FinmJA-1; Mon, 21 Dec 2020 05:58:53 -0500 X-MC-Unique: q1mUze6SP9KhSAY1FinmJA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D3BC2800D55; Mon, 21 Dec 2020 10:58:52 +0000 (UTC) Received: from [10.36.110.46] (unknown [10.36.110.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9B8892BCF4; Mon, 21 Dec 2020 10:58:48 +0000 (UTC) To: dev@dpdk.org, chenbo.xia@intel.com, olivier.matz@6wind.com, amorenoz@redhat.com, david.marchand@redhat.com References: <20201220211405.313012-1-maxime.coquelin@redhat.com> From: Maxime Coquelin Message-ID: <0aaedd10-cf6f-48ff-7bd5-6d612ba0131d@redhat.com> Date: Mon, 21 Dec 2020 11:58:46 +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: <20201220211405.313012-1-maxime.coquelin@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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 00/40] net/virtio: Virtio PMD rework 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" On 12/20/20 10:13 PM, Maxime Coquelin wrote: > This series significantly rework Virtio PMD to improve > the Virtio-user PMD and its backends integration. > > First part of the series (first 21 patches) removes the > dependency of Virtio-user ethdev on Virtio PCI, by > creating generic files, adding per-bus meta data, ... > > Main (if not single) functionnal change of this first > part is to remove the hack for Virtio-user to work in > IOVA as PA mode, this hack being very fragile. Now, the > user has to manually pass --iova-mode=va in EAL > parameters, otherwise vdev probe will fail. In v21.11, > when ABI/API can be changed, I will add vdev driver > flags so that the Virtio-user PMD can request IOVA as VA > mode to be used. > > Second part of the series reworks Virtio-user internal, > by reworking the requests handling so that vDPA and Kernel > backends no more hack into being Vhost-user backend. It > implies implementing new ops for all the request types. > Also, all the backend specific actions are moved from the > virtio_user_dev.c and virtio_user_ethdev.c to their > backend files. > > Only functionnal change in this second part is making the > Vhost-user server mode blocking at init time, as long as > a client is not connected. The goal of this change is to > make the Vhost-user support much more robust, as without > blocking, the driver has to assume features that are going > to be supported by the client, which is very fragile and > error prone. As a side-effect, it also simplifies the > logic nin several place of the virtio-user PMD. > > Plese note that I haven't tested the last 5 patches yet, > I will conduct more testing early next week. I forgot to add the remaining things to do in next release: 1. More testing 2. Rebase on top of Vhost-vDPA batching support 3. Rebase on top of Olivier's protocol features fix 4. (Maybe) Loosen restrictions on IOVA as VA mode, by making Vhost- backend to use IOVA instead of directly VAs, but still warn IOVA as VA mode is advised to ensure init won't fail. Regards, Maxime