lkml.org 
[lkml]   [2023]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC 0/2] vduse: add support for networking devices
On Wed, Apr 19, 2023 at 9:44 PM Maxime Coquelin
<maxime.coquelin@redhat.com> 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 [0] using split rings layout.
>
> Control queue support (and so multiqueue) has also been
> tested, but require a Kernel series from Jason Wang
> relaxing control queue polling [1] to function reliably.
>
> Other than that, we have identified a few gaps:
>
> 1. Reconnection:
> a. VDUSE_VQ_GET_INFO ioctl() returns always 0 for avail
> index, even after the virtqueue has already been
> processed. Is that expected? I have tried instead to
> get the driver's avail index directly from the avail
> ring, but it does not seem reliable as I sometimes get
> "id %u is not a head!\n" warnings. Also such solution
> would not be possible with packed ring, as we need to
> know the wrap counters values.
>

I'm not sure how to handle the reconnection in the vhost-user-net
case. Can we use a tmpfs file to track inflight I/O like this [1]

[1] https://qemu-project.gitlab.io/qemu/interop/vhost-user.html#inflight-i-o-tracking

> b. Missing IOCTLs: it would be handy to have new IOCTLs to
> query Virtio device status, and retrieve the config
> space set at VDUSE_CREATE_DEV time.
>

VDUSE_GET_STATUS ioctl might be needed. Or can we use a tmpfs file to
save/restore that info.

> 2. VDUSE application as non-root:
> We need to run the VDUSE application as non-root. There
> is some race between the time the UDEV rule is applied
> and the time the device starts being used. Discussing
> with Jason, he suggested we may have a VDUSE daemon run
> as root that would create the VDUSE device, manages its
> rights and then pass its file descriptor to the VDUSE
> app. However, with current IOCTLs, it means the VDUSE
> daemon would need to know several information that
> belongs to the VDUSE app implementing the device such
> as supported Virtio features, config space, etc...
> If we go that route, maybe we should have a control
> IOCTL to create the device which would just pass the
> device type. Then another device IOCTL to perform the
> initialization. Would that make sense?
>

I think we can reuse the VDUSE_CREATE_DEV ioctl (just use name,
device_id and vendor_id) for control device here, and add a new ioctl
VDUSE_DEV_SETUP to do device initialization.

Thanks,
Yongji

\
 
 \ /
  Last update: 2023-04-20 10:15    [W:0.117 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site