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 at nvidia.com>
wrote:
>>
>>
>>
>> > From: Stefano Garzarella <sgarzare at redhat.com>
>> > 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