Re: vDPA bus driver selection

From: Stefano Garzarella <sgarzare@redhat.com>
To: Jason Wang <jasowang@redhat.com>, Parav Pandit <parav@nvidia.com>
Cc: Eli Cohen <elic@nvidia.com>,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	Michael Tsirkin <mst@redhat.com>
Subject: Re: vDPA bus driver selection
Date: Fri, 29 Oct 2021 16:41:00 +0200	[thread overview]
Message-ID: <20211029144100.eybykx7o4tpwmjph@steredhat> (raw)
In-Reply-To: <CACGkMEt+iwKc=O552rsMUWdmT1MGVpUJrKsjdjv7mv=4uX1uOQ@mail.gmail.com>

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

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization