Virtualization - Jul 2023 - [PATCH v1 0/2] vduse: add support for networking devices

On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin
wrote:
> 
> On 7/3/23 08:44, Jason Wang wrote:
> > On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at
redhat.com> wrote:
> > > 
> > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote:
> > > > This small series enables virtio-net device type in VDUSE.
> > > > With it, basic operation have been tested, both with
> > > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series
> > > > adding VDUSE support using split rings layout (merged in
> > > > DPDK v23.07-rc1).
> > > > 
> > > > Control queue support (and so multiqueue) has also been
> > > > tested, but requires a Kernel series from Jason Wang
> > > > relaxing control queue polling [1] to function reliably.
> > > > 
> > > > [1]:
https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg
at mail.gmail.com/T/
> > > 
> > > Jason promised to post a new version of that patch.
> > > Right Jason?
> > 
> > Yes.
> > 
> > > For now let's make sure CVQ feature flag is off?
> > 
> > We can do that and relax on top of my patch.
> 
> I agree? Do you prefer a features negotiation, or failing init (like
> done for VERSION_1) if the VDUSE application advertises CVQ?
> 
> Thanks,
> Maxime
Unfortunately guests fail probe if feature set is inconsistent.
So I don't think passing through features is a good idea,
you need a list of legal bits. And when doing this,
clear CVQ and everything that depends on it.


> > Thanks
> > 
> > > 
> > > > RFC -> v1 changes:
> > > > =================> > > > - Fail device init if
it does not support VERSION_1 (Jason)
> > > > 
> > > > Maxime Coquelin (2):
> > > >    vduse: validate block features only with block devices
> > > >    vduse: enable Virtio-net device type
> > > > 
> > > >   drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++----
> > > >   1 file changed, 11 insertions(+), 4 deletions(-)
> > > > 
> > > > --
> > > > 2.41.0
> > > 
> >

On 7/3/23 23:45, Michael S. Tsirkin wrote:
> On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote:
>>
>> On 7/3/23 08:44, Jason Wang wrote:
>>> On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at
redhat.com> wrote:
>>>>
>>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin
wrote:
>>>>> This small series enables virtio-net device type in VDUSE.
>>>>> With it, basic operation have been tested, both with
>>>>> virtio-vdpa and vhost-vdpa using DPDK Vhost library series
>>>>> adding VDUSE support using split rings layout (merged in
>>>>> DPDK v23.07-rc1).
>>>>>
>>>>> Control queue support (and so multiqueue) has also been
>>>>> tested, but requires a Kernel series from Jason Wang
>>>>> relaxing control queue polling [1] to function reliably.
>>>>>
>>>>> [1]:
https://lore.kernel.org/lkml/CACGkMEtgrxN3PPwsDo4oOsnsSLJfEmBEZ0WvjGRr3whU+QasUg
at mail.gmail.com/T/
>>>>
>>>> Jason promised to post a new version of that patch.
>>>> Right Jason?
>>>
>>> Yes.
>>>
>>>> For now let's make sure CVQ feature flag is off?
>>>
>>> We can do that and relax on top of my patch.
>>
>> I agree? Do you prefer a features negotiation, or failing init (like
>> done for VERSION_1) if the VDUSE application advertises CVQ?
>>
>> Thanks,
>> Maxime
> 
> Unfortunately guests fail probe if feature set is inconsistent.
> So I don't think passing through features is a good idea,
> you need a list of legal bits. And when doing this,
> clear CVQ and everything that depends on it.
Since this is temporary, while cvq is made more robust, I think it is
better to fail VDUSE device creation if CVQ feature is advertised by the
VDUSE application, instead of ensuring features depending on CVQ are
also cleared.

Jason seems to think likewise, would that work for you?

Thanks,
Maxime
> 
> 
>>> Thanks
>>>
>>>>
>>>>> RFC -> v1 changes:
>>>>> =================>>>>> - Fail device init if
it does not support VERSION_1 (Jason)
>>>>>
>>>>> Maxime Coquelin (2):
>>>>>     vduse: validate block features only with block devices
>>>>>     vduse: enable Virtio-net device type
>>>>>
>>>>>    drivers/vdpa/vdpa_user/vduse_dev.c | 15 +++++++++++----
>>>>>    1 file changed, 11 insertions(+), 4 deletions(-)
>>>>>
>>>>> --
>>>>> 2.41.0
>>>>
>>>
>