On Tue, Dec 1, 2020 at 2:25 PM Jason Wang <jasow...@redhat.com> wrote: > > > On 2020/11/30 下午3:07, Yongji Xie wrote: > >>> 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
