On Fri, Oct 29, 2021 at 10:34:00AM +0800, Jason Wang wrote:
On Thu, Oct 28, 2021 at 5:48 PM Parav Pandit <parav@xxxxxxxxxx> wrote:
> From: Stefano Garzarella <sgarzare@xxxxxxxxxx>
> Sent: Thursday, October 28, 2021 3:08 PM
> >> >$ vdpa/vdpa dev add mgmtdev vdpasim_net name vdpa0 mac
> >> >00:11:22:33:44:55 $ echo 0 > /sys/bus/vdpa/drivers_autoprobe
> >> >
> >> >And after vdpa device creation, it manually binds to the desired
> >> >driver such as,
> >> >
> >> >$ echo vdpa0 > /sys/bus/vdpa/drivers/virtio_vdpa/bind
> >> >Or
> >> >$ echo vdpa0 > /sys/bus/vdpa/drivers/vhost_vdpa/bind
> >>
> >> Cool, I didn't know that. This is very useful, but do you think it
> >> might be better to integrate it with the netlink API and specify at
> >> creation which bus driver to use?
> >I think it is useful; for vduse case we need the ability to say "none"
> >as well and when nothing specified it should be default driver.
>
> Yep, the default can be the actual behaviour.
>
> >
> >More than netlink, I think we need the ability in the core kernel to
> >make this choice.
>
> Okay, but I think we can include that in the vdpa tool.
If functionality and interface exists in other part of the it is hard to wrap that in vdpa tool that does the duplicate work.
Got it.
>
> >I haven't explored what is already available to make that happen.
>
> Me too, I only saw the .match() callback of "struct bus_type" that could be used
> for this purpose.
>
> >If/once its available, I am sure it has more users than just vdpa.
>
> Make sense. I'll spend some time next week.
Ok. yeah, may be a desired driver can be stored in the vdpa_device that match() routine can use.
And if that driver is not available, it returns EPROBE_DEFER; so whenever such driver is loaded it can be bind.
But I think before wrapping something in vdpa, need to find a reason why the current interface doesn't solve the problem and also to figure out plumbing.
Yep, when I started this thread I wasn't aware of that APIs available
through sysfs.
It could be useful to start documenting vDPA (life cycle, management
API, etc.). I have a plan to add some vDPA docs in linux/Documentation,
maybe we can include also these things.
I agree. If it's something that can easily be addressed by the
management code (just a matter of the extra steps for manual setup).
It's probably not worth bothering.
Yep, I agree too. It seems we can easily switch the vDPA bus driver at
runtime.
Maybe the only missing point is a way to specify the default bus driver
to use for a device. Of course the workaround is to unbind it and bind
to the desired one.
Thank you so much for this very helpful discussion,
Stefano
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
