Message ID | 20230627113652.65283-1-maxime.coquelin@redhat.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp8147411vqr; Tue, 27 Jun 2023 05:14:17 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5EN5Bbo83N++GX/ZJFdjpOtf/Tcx47D17EcfbRuLQvCbUZWzmG6rhhf0J/MyEdabv8hOHf X-Received: by 2002:a05:6a00:2d85:b0:67f:830f:b809 with SMTP id fb5-20020a056a002d8500b0067f830fb809mr90572pfb.3.1687868056636; Tue, 27 Jun 2023 05:14:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687868056; cv=none; d=google.com; s=arc-20160816; b=1JYLob6cGCLXcRqnbthDHKfMXgLNgrb9zGNdzkxNPMoG+I0kyjIZ2wDhAqxE/mNHDW JqRXwJgvJcr+RLoIINfhA2N8SDTYtGoZpZka2zbzkzvekIKgcrNxZ+7cx36dloKD9d/i m7jc/8TOjSsm6E4l2ER7z5Og/WS5nILsyrgDF7wYDFDj3MsjKlG6vfzEOK0buAAa4Cz+ AwxiwFWx2pSpKiVVbkk7wQ9ilf/RatOQgk5Uune+334fIm+QVuY8z10G/zsaGPOhDRTt AYz1Fim7a/m52p214Nn/b+GSEbsRh0IwAv4Ga+vyq2XhLHaxWLP5PSw3PVTdRvPyhwWD 0RkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Tdurvxft1YKsdJG5IOcbskrBx73tXYW6QLBL2YhfQC0=; fh=S1rZK6DPg0mAED4KjNm0cP4EEY87q6FXHFEeosELg0E=; b=ZmyK9ekfMw5Sq3q1q1hDvRqUz/OdyUH7PqFG3MjWgrV6qa4T+s/3bmHebe2rLAjKFC gOb1kTfcH74tUvtQNkzOCB+tM1OIujBIXTGCVyCexnfgKR7UMtNVpK/QJEGuukD2Rhf6 YcaapxhrkGGDlthHOD4wYUOyEQrbQDV56H8nlLsJV+gtWCck9NB2Du98wul0hp9wlHpo +4IofaYxXQBtkatMtNsLQvy7LaugAcepdcYy42TJ8nCf2sfP1faWnyj7kbWv4LM+av6n Xy6XREK3plqtCutgcIRT3Eqf6gQ2//tp0QXL5XU7RxCXd0n5rs4HaPL+Eun33inmKIwe 5Y/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CxQ8vuDQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d18-20020a056a00199200b00648019bae38si7025658pfl.277.2023.06.27.05.13.49; Tue, 27 Jun 2023 05:14:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CxQ8vuDQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230340AbjF0LiK (ORCPT <rfc822;nicolai.engesland@gmail.com> + 99 others); Tue, 27 Jun 2023 07:38:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231182AbjF0LiG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Jun 2023 07:38:06 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CC3310FB for <linux-kernel@vger.kernel.org>; Tue, 27 Jun 2023 04:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687865842; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Tdurvxft1YKsdJG5IOcbskrBx73tXYW6QLBL2YhfQC0=; b=CxQ8vuDQ+CNg2Jd/OzleKRY/CLcN2lLy04oug9Q3yUd/Soqu4nUekZUke8KRdr5NoxJw0C nBT2Xz8B+zGHtf98j9OTt3dP4FSi8Tr+xEmZ1eTroZduJSPkjRImYspAuFZN0EDd2dqq95 M2RaS/dKsupGdTawLo9aBmBYBv+OaMQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-590-KcYV-GFPMhK3r4fVNxggkg-1; Tue, 27 Jun 2023 07:37:19 -0400 X-MC-Unique: KcYV-GFPMhK3r4fVNxggkg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0A781C06EE7; Tue, 27 Jun 2023 11:37:18 +0000 (UTC) Received: from max-t490s.redhat.com (unknown [10.39.208.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 55BA7F5CD0; Tue, 27 Jun 2023 11:37:15 +0000 (UTC) From: Maxime Coquelin <maxime.coquelin@redhat.com> To: xieyongji@bytedance.com, jasowang@redhat.com, mst@redhat.com, david.marchand@redhat.com, lulu@redhat.com Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, xuanzhuo@linux.alibaba.com, eperezma@redhat.com, Maxime Coquelin <maxime.coquelin@redhat.com> Subject: [PATCH v1 0/2] vduse: add support for networking devices Date: Tue, 27 Jun 2023 13:36:50 +0200 Message-ID: <20230627113652.65283-1-maxime.coquelin@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769857935678229598?= X-GMAIL-MSGID: =?utf-8?q?1769857935678229598?= |
Series |
vduse: add support for networking devices
|
|
Message
Maxime Coquelin
June 27, 2023, 11:36 a.m. UTC
This small series enables virtio-net device type in VDUSE. With it, basic operation have been tested, both with virtio-vdpa and vhost-vdpa using DPDK Vhost library series adding VDUSE support using split rings layout (merged in DPDK v23.07-rc1). Control queue support (and so multiqueue) has also been tested, but requires a Kernel series from Jason Wang relaxing control queue polling [1] to function reliably. [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ RFC -> v1 changes: ================== - Fail device init if it does not support VERSION_1 (Jason) Maxime Coquelin (2): vduse: validate block features only with block devices vduse: enable Virtio-net device type drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
Comments
On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > This small series enables virtio-net device type in VDUSE. > With it, basic operation have been tested, both with > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > adding VDUSE support using split rings layout (merged in > DPDK v23.07-rc1). > > Control queue support (and so multiqueue) has also been > tested, but requires a Kernel series from Jason Wang > relaxing control queue polling [1] to function reliably. > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ Jason promised to post a new version of that patch. Right Jason? For now let's make sure CVQ feature flag is off? > RFC -> v1 changes: > ================== > - Fail device init if it does not support VERSION_1 (Jason) > > Maxime Coquelin (2): > vduse: validate block features only with block devices > vduse: enable Virtio-net device type > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > -- > 2.41.0
On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > This small series enables virtio-net device type in VDUSE. > > With it, basic operation have been tested, both with > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > adding VDUSE support using split rings layout (merged in > > DPDK v23.07-rc1). > > > > Control queue support (and so multiqueue) has also been > > tested, but requires a Kernel series from Jason Wang > > relaxing control queue polling [1] to function reliably. > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > Jason promised to post a new version of that patch. > Right Jason? Yes. > For now let's make sure CVQ feature flag is off? We can do that and relax on top of my patch. Thanks > > > RFC -> v1 changes: > > ================== > > - Fail device init if it does not support VERSION_1 (Jason) > > > > Maxime Coquelin (2): > > vduse: validate block features only with block devices > > vduse: enable Virtio-net device type > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > -- > > 2.41.0 >
On 7/3/23 08:44, Jason Wang wrote: > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >> >> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>> This small series enables virtio-net device type in VDUSE. >>> With it, basic operation have been tested, both with >>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>> adding VDUSE support using split rings layout (merged in >>> DPDK v23.07-rc1). >>> >>> Control queue support (and so multiqueue) has also been >>> tested, but requires a Kernel series from Jason Wang >>> relaxing control queue polling [1] to function reliably. >>> >>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >> >> Jason promised to post a new version of that patch. >> Right Jason? > > Yes. > >> For now let's make sure CVQ feature flag is off? > > We can do that and relax on top of my patch. I agree? Do you prefer a features negotiation, or failing init (like done for VERSION_1) if the VDUSE application advertises CVQ? Thanks, Maxime > Thanks > >> >>> RFC -> v1 changes: >>> ================== >>> - Fail device init if it does not support VERSION_1 (Jason) >>> >>> Maxime Coquelin (2): >>> vduse: validate block features only with block devices >>> vduse: enable Virtio-net device type >>> >>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>> 1 file changed, 11 insertions(+), 4 deletions(-) >>> >>> -- >>> 2.41.0 >> >
On Mon, Jul 3, 2023 at 3:43 PM Maxime Coquelin <maxime.coquelin@redhat.com> wrote: > > > On 7/3/23 08:44, Jason Wang wrote: > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > >> > >> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > >>> This small series enables virtio-net device type in VDUSE. > >>> With it, basic operation have been tested, both with > >>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series > >>> adding VDUSE support using split rings layout (merged in > >>> DPDK v23.07-rc1). > >>> > >>> Control queue support (and so multiqueue) has also been > >>> tested, but requires a Kernel series from Jason Wang > >>> relaxing control queue polling [1] to function reliably. > >>> > >>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > >> > >> Jason promised to post a new version of that patch. > >> Right Jason? > > > > Yes. > > > >> For now let's make sure CVQ feature flag is off? > > > > We can do that and relax on top of my patch. > > I agree? Do you prefer a features negotiation, or failing init (like > done for VERSION_1) if the VDUSE application advertises CVQ? Assuming we will relax it soon, I think we can choose the easier way. I guess it's just failing. Thanks > > Thanks, > Maxime > > > Thanks > > > >> > >>> RFC -> v1 changes: > >>> ================== > >>> - Fail device init if it does not support VERSION_1 (Jason) > >>> > >>> Maxime Coquelin (2): > >>> vduse: validate block features only with block devices > >>> vduse: enable Virtio-net device type > >>> > >>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > >>> 1 file changed, 11 insertions(+), 4 deletions(-) > >>> > >>> -- > >>> 2.41.0 > >> > > >
On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > On 7/3/23 08:44, Jason Wang wrote: > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > > > This small series enables virtio-net device type in VDUSE. > > > > With it, basic operation have been tested, both with > > > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > > > adding VDUSE support using split rings layout (merged in > > > > DPDK v23.07-rc1). > > > > > > > > Control queue support (and so multiqueue) has also been > > > > tested, but requires a Kernel series from Jason Wang > > > > relaxing control queue polling [1] to function reliably. > > > > > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > > > > > Jason promised to post a new version of that patch. > > > Right Jason? > > > > Yes. > > > > > For now let's make sure CVQ feature flag is off? > > > > We can do that and relax on top of my patch. > > I agree? Do you prefer a features negotiation, or failing init (like > done for VERSION_1) if the VDUSE application advertises CVQ? > > Thanks, > Maxime Unfortunately guests fail probe if feature set is inconsistent. So I don't think passing through features is a good idea, you need a list of legal bits. And when doing this, clear CVQ and everything that depends on it. > > Thanks > > > > > > > > > RFC -> v1 changes: > > > > ================== > > > > - Fail device init if it does not support VERSION_1 (Jason) > > > > > > > > Maxime Coquelin (2): > > > > vduse: validate block features only with block devices > > > > vduse: enable Virtio-net device type > > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > > > > > -- > > > > 2.41.0 > > > > >
On 7/3/23 23:45, Michael S. Tsirkin wrote: > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: >> >> On 7/3/23 08:44, Jason Wang wrote: >>> On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>>> >>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>>>> This small series enables virtio-net device type in VDUSE. >>>>> With it, basic operation have been tested, both with >>>>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>>>> adding VDUSE support using split rings layout (merged in >>>>> DPDK v23.07-rc1). >>>>> >>>>> Control queue support (and so multiqueue) has also been >>>>> tested, but requires a Kernel series from Jason Wang >>>>> relaxing control queue polling [1] to function reliably. >>>>> >>>>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >>>> >>>> Jason promised to post a new version of that patch. >>>> Right Jason? >>> >>> Yes. >>> >>>> For now let's make sure CVQ feature flag is off? >>> >>> We can do that and relax on top of my patch. >> >> I agree? Do you prefer a features negotiation, or failing init (like >> done for VERSION_1) if the VDUSE application advertises CVQ? >> >> Thanks, >> Maxime > > Unfortunately guests fail probe if feature set is inconsistent. > So I don't think passing through features is a good idea, > you need a list of legal bits. And when doing this, > clear CVQ and everything that depends on it. Since this is temporary, while cvq is made more robust, I think it is better to fail VDUSE device creation if CVQ feature is advertised by the VDUSE application, instead of ensuring features depending on CVQ are also cleared. Jason seems to think likewise, would that work for you? Thanks, Maxime > > >>> Thanks >>> >>>> >>>>> RFC -> v1 changes: >>>>> ================== >>>>> - Fail device init if it does not support VERSION_1 (Jason) >>>>> >>>>> Maxime Coquelin (2): >>>>> vduse: validate block features only with block devices >>>>> vduse: enable Virtio-net device type >>>>> >>>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>>>> 1 file changed, 11 insertions(+), 4 deletions(-) >>>>> >>>>> -- >>>>> 2.41.0 >>>> >>> >
On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin wrote: > > > On 7/3/23 23:45, Michael S. Tsirkin wrote: > > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > > > > > On 7/3/23 08:44, Jason Wang wrote: > > > > On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > > > > > This small series enables virtio-net device type in VDUSE. > > > > > > With it, basic operation have been tested, both with > > > > > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > > > > > adding VDUSE support using split rings layout (merged in > > > > > > DPDK v23.07-rc1). > > > > > > > > > > > > Control queue support (and so multiqueue) has also been > > > > > > tested, but requires a Kernel series from Jason Wang > > > > > > relaxing control queue polling [1] to function reliably. > > > > > > > > > > > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > > > > > > > > > Jason promised to post a new version of that patch. > > > > > Right Jason? > > > > > > > > Yes. > > > > > > > > > For now let's make sure CVQ feature flag is off? > > > > > > > > We can do that and relax on top of my patch. > > > > > > I agree? Do you prefer a features negotiation, or failing init (like > > > done for VERSION_1) if the VDUSE application advertises CVQ? > > > > > > Thanks, > > > Maxime > > > > Unfortunately guests fail probe if feature set is inconsistent. > > So I don't think passing through features is a good idea, > > you need a list of legal bits. And when doing this, > > clear CVQ and everything that depends on it. > > Since this is temporary, while cvq is made more robust, I think it is > better to fail VDUSE device creation if CVQ feature is advertised by the > VDUSE application, instead of ensuring features depending on CVQ are > also cleared. > > Jason seems to think likewise, would that work for you? > > Thanks, > Maxime Nothing is more permanent than temporary solutions. My concern would be that hardware devices then start masking CVQ intentionally just to avoid the pain of broken software. > > > > > > > > Thanks > > > > > > > > > > > > > > > RFC -> v1 changes: > > > > > > ================== > > > > > > - Fail device init if it does not support VERSION_1 (Jason) > > > > > > > > > > > > Maxime Coquelin (2): > > > > > > vduse: validate block features only with block devices > > > > > > vduse: enable Virtio-net device type > > > > > > > > > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > > > > > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.41.0 > > > > > > > > > > >
On 7/4/23 11:59, Michael S. Tsirkin wrote: > On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin wrote: >> >> >> On 7/3/23 23:45, Michael S. Tsirkin wrote: >>> On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: >>>> >>>> On 7/3/23 08:44, Jason Wang wrote: >>>>> On Sun, Jul 2, 2023 at 9:37 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>>>>> >>>>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>>>>>> This small series enables virtio-net device type in VDUSE. >>>>>>> With it, basic operation have been tested, both with >>>>>>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series >>>>>>> adding VDUSE support using split rings layout (merged in >>>>>>> DPDK v23.07-rc1). >>>>>>> >>>>>>> Control queue support (and so multiqueue) has also been >>>>>>> tested, but requires a Kernel series from Jason Wang >>>>>>> relaxing control queue polling [1] to function reliably. >>>>>>> >>>>>>> [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ >>>>>> >>>>>> Jason promised to post a new version of that patch. >>>>>> Right Jason? >>>>> >>>>> Yes. >>>>> >>>>>> For now let's make sure CVQ feature flag is off? >>>>> >>>>> We can do that and relax on top of my patch. >>>> >>>> I agree? Do you prefer a features negotiation, or failing init (like >>>> done for VERSION_1) if the VDUSE application advertises CVQ? >>>> >>>> Thanks, >>>> Maxime >>> >>> Unfortunately guests fail probe if feature set is inconsistent. >>> So I don't think passing through features is a good idea, >>> you need a list of legal bits. And when doing this, >>> clear CVQ and everything that depends on it. >> >> Since this is temporary, while cvq is made more robust, I think it is >> better to fail VDUSE device creation if CVQ feature is advertised by the >> VDUSE application, instead of ensuring features depending on CVQ are >> also cleared. >> >> Jason seems to think likewise, would that work for you? >> >> Thanks, >> Maxime > > Nothing is more permanent than temporary solutions. > My concern would be that hardware devices then start masking CVQ > intentionally just to avoid the pain of broken software. Got it, I'll add a patch on top that filters out CVQ feature and all the features that depend on it. Thanks, Maxime > >>> >>> >>>>> Thanks >>>>> >>>>>> >>>>>>> RFC -> v1 changes: >>>>>>> ================== >>>>>>> - Fail device init if it does not support VERSION_1 (Jason) >>>>>>> >>>>>>> Maxime Coquelin (2): >>>>>>> vduse: validate block features only with block devices >>>>>>> vduse: enable Virtio-net device type >>>>>>> >>>>>>> drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- >>>>>>> 1 file changed, 11 insertions(+), 4 deletions(-) >>>>>>> >>>>>>> -- >>>>>>> 2.41.0 >>>>>> >>>>> >>> >
On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > This small series enables virtio-net device type in VDUSE. > With it, basic operation have been tested, both with > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > adding VDUSE support using split rings layout (merged in > DPDK v23.07-rc1). > > Control queue support (and so multiqueue) has also been > tested, but requires a Kernel series from Jason Wang > relaxing control queue polling [1] to function reliably. > > [1]: https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg@mail.gmail.com/T/ > > RFC -> v1 changes: > ================== > - Fail device init if it does not support VERSION_1 (Jason) So I can put this in next, the issue I think is that of security: currently selinux can if necessary block access to creating virtio block devices. But if we have more than one type we need a way for selinux to block specific types. Can be a patch on top but pls work to address. Another question is that with this userspace can inject packets directly into net stack. Should we check CAP_NET_ADMIN or such? > Maxime Coquelin (2): > vduse: validate block features only with block devices > vduse: enable Virtio-net device type > > drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > -- > 2.41.0