On Tue, Dec 1, 2020 at 2:25 PM Jason Wang [off-list ref] wrote:

On 2020/11/30 下午3:07, Yongji Xie wrote:

quoted

quoted

quoted

Thanks for adding me, Jason!

Now I'm working on a v2 patchset for VDUSE (vDPA Device in Userspace)
[1]. This tool is very useful for the vduse device. So I'm considering
integrating this into my v2 patchset. But there is one problem：

In this tool, vdpa device config action and enable action are combined
into one netlink msg: VDPA_CMD_DEV_NEW. But in vduse case, it needs to
be splitted because a chardev should be created and opened by a
userspace process before we enable the vdpa device (call
vdpa_register_device()).

So I'd like to know whether it's possible (or have some plans) to add
two new netlink msgs something like: VDPA_CMD_DEV_ENABLE and
VDPA_CMD_DEV_DISABLE to make the config path more flexible.

Actually, we've discussed such intermediate step in some early
discussion. It looks to me VDUSE could be one of the users of this.

Or I wonder whether we can switch to use anonymous inode(fd) for VDUSE
then fetching it via an VDUSE_GET_DEVICE_FD ioctl?

Yes, we can. Actually the current implementation in VDUSE is like
this.  But seems like this is still a intermediate step. The fd should
be binded to a name or something else which need to be configured
before.

The name could be specified via the netlink. It looks to me the real
issue is that until the device is connected with a userspace, it can't
be used. So we also need to fail the enabling if it doesn't opened.

Yes, that's true. So you mean we can firstly try to fetch the fd
binded to a name/vduse_id via an VDUSE_GET_DEVICE_FD, then use the
name/vduse_id as a attribute to create vdpa device? It looks fine to
me.

Thanks,
Yongji