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

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
>>>>
>>>
>

On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin
wrote:
> 
> 
> 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
Nothing is more permanent than temporary solutions.
My concern would be that hardware devices then start masking CVQ
intentionally just to avoid the pain of broken software.
> > 
> > 
> > > > 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
> > > > > 
> > > > 
> >