All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: David Marchand <david.marchand@redhat.com>, dev@dpdk.org
Cc: olivier.matz@6wind.com, Chenbo Xia <chenbo.xia@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] net/virtio: fix virtio-user init when using existing tap
Date: Tue, 28 Sep 2021 12:12:09 +0200	[thread overview]
Message-ID: <9c3ef9b7-c5a9-6267-2bb8-f2a8b61697a0@redhat.com> (raw)
In-Reply-To: <20210928085114.30737-1-david.marchand@redhat.com>



On 9/28/21 10:51, David Marchand wrote:
> When attaching to an existing mono queue tap, the virtio-user was not
> reporting that the virtio device was not properly initialised which
> prevented from starting the port later.
> 
> $ ip tuntap add test mode tap
> $ dpdk-testpmd --vdev \
>    net_virtio_user0,iface=test,path=/dev/vhost-net,queues=2 -- -i
> 
> ...
> virtio_user_dev_init_mac(): (/dev/vhost-net) No valid MAC in devargs or
> device, use random
> vhost_kernel_open_tap(): TUNSETIFF failed: Invalid argument
> vhost_kernel_enable_queue_pair(): fail to open tap for vhost kernel
> virtio_user_start_device(): (/dev/vhost-net) Failed to start device
> ...
> Configuring Port 0 (socket 0)
> vhost_kernel_open_tap(): TUNSETIFF failed: Invalid argument
> vhost_kernel_enable_queue_pair(): fail to open tap for vhost kernel
> virtio_set_multiple_queues(): Multiqueue configured but send command
> failed, this is too late now...
> Fail to start port 0: Invalid argument
> Please stop the ports first
> Done
> 
> The virtio-user with vhost-kernel backend was going through a lot
> of complications to initialise tap fds only when using them.
> 
> For each qp enabled for the first time, a tapfd was created via
> TUNSETIFF with unneeded additional steps (see below) and then mapped to
> the right qp in the vhost-net backend.
> Unneeded steps (as long as it has been done once for the port):
> - tap features were queried while this is a constant on a running
>    system,
> - the device name in DPDK was updated,
> - the mac address of the tap was set,
> 
> On subsequent qps state change, the vhost-net backend fd mapping was
> updated and the associated queue/tapfd were disabled/enabled via
> TUNSETQUEUE.
> 
> Now, this patch simplifies the whole logic by keeping all tapfds opened
> and in enabled state (from the tap point of view) at all time.
> 
> Unused ioctl defines are removed.
> 
> Tap features are validated earlier to fail initialisation asap.
> Tap name discovery and mac address configuration are moved when
> configuring qp 0.
> 
> To support attaching to mono queue tap, the virtio-user driver now tries
> to attach in multi queue first, then fallbacks to mono queue.
> 
> Finally (but this is more for consistency), VIRTIO_NET_F_MQ feature is
> exposed only if the underlying tap supports multi queue.
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changes since v1:
> - refactored tap_open() following Olivier comment and updated log
>    messages level accordingly,
> - added more error logs,
> 
> ---
> 
>   drivers/net/virtio/virtio_user/vhost_kernel.c |  92 +++++----
>   .../net/virtio/virtio_user/vhost_kernel_tap.c | 180 +++++++++---------
>   .../net/virtio/virtio_user/vhost_kernel_tap.h |  16 +-
>   3 files changed, 153 insertions(+), 135 deletions(-)
> 

Nice, thanks for the detailed commit message.

Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>

Thanks,
Maxime


  reply	other threads:[~2021-09-28 10:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17  9:33 [dpdk-dev] [PATCH] net/virtio: fix virtio-user init when using existing tap David Marchand
2021-09-23 15:39 ` Olivier Matz
2021-09-23 16:45   ` David Marchand
2021-09-28  8:51 ` [dpdk-dev] [PATCH v2] " David Marchand
2021-09-28 10:12   ` Maxime Coquelin [this message]
2021-09-29 13:19   ` Ferruh Yigit
2021-09-30  9:27     ` Maxime Coquelin
2021-09-28 15:38 ` [dpdk-dev] [PATCH] " Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c3ef9b7-c5a9-6267-2bb8-f2a8b61697a0@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.