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,
so while Jason rework is done, a patch is added to fail init
if control queue feature is requested.(tested also with DPDK
v23.11).


Changes in v7:
==============
- Fail init only if VIRTIO_NET_F_CTRL_VQ is requested.
- Convert to use BIT_ULL() macro
- Rebased

Changes in v6:
==============
- Remove SELinux support from the series, will be handled
  in a dedicated one.
- Require CAP_NET_ADMIN for Net devices creation (Jason).
- Fail init if control queue features are requested for
  Net device type (Jason).
- Rebased on latest master.

Changes in v5:
==============
- Move control queue disablement patch before Net
  devices enablement (Jason).
- Unify operations LSM hooks into a single hook.
- Rebase on latest master.

Maxime Coquelin (3):
  vduse: validate block features only with block devices
  vduse: Temporarily fail if control queue feature requested
  vduse: enable Virtio-net device type

 drivers/vdpa/vdpa_user/vduse_dev.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

-- 
2.43.0

Hi Jason,

It looks like all patches got acked by you.
Any blocker to queue the series for next release?

Thanks,
Maxime

On 1/9/24 12:10, 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,
> so while Jason rework is done, a patch is added to fail init
> if control queue feature is requested.(tested also with DPDK
> v23.11).
> 
> 
> Changes in v7:
> ==============
> - Fail init only if VIRTIO_NET_F_CTRL_VQ is requested.
> - Convert to use BIT_ULL() macro
> - Rebased
> 
> Changes in v6:
> ==============
> - Remove SELinux support from the series, will be handled
>    in a dedicated one.
> - Require CAP_NET_ADMIN for Net devices creation (Jason).
> - Fail init if control queue features are requested for
>    Net device type (Jason).
> - Rebased on latest master.
> 
> Changes in v5:
> ==============
> - Move control queue disablement patch before Net
>    devices enablement (Jason).
> - Unify operations LSM hooks into a single hook.
> - Rebase on latest master.
> 
> Maxime Coquelin (3):
>    vduse: validate block features only with block devices
>    vduse: Temporarily fail if control queue feature requested
>    vduse: enable Virtio-net device type
> 
>   drivers/vdpa/vdpa_user/vduse_dev.c | 24 ++++++++++++++++++++----
>   1 file changed, 20 insertions(+), 4 deletions(-)
>

On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
> Hi Jason,
> 
> It looks like all patches got acked by you.
> Any blocker to queue the series for next release?
> 
> Thanks,
> Maxime

I think it's good enough at this point. Will put it in
linux-next shortly.

Hello Michael,

On 2/1/24 09:40, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
>> Hi Jason,
>>
>> It looks like all patches got acked by you.
>> Any blocker to queue the series for next release?
>>
>> Thanks,
>> Maxime
> 
> I think it's good enough at this point. Will put it in
> linux-next shortly.
> 

I fetched linux-next and it seems the series is not in yet.
Is there anything to be reworked on my side?

Thanks,
Maxime

On Thu, Feb 29, 2024 at 11:16:04AM +0100, Maxime Coquelin wrote:
> Hello Michael,
> 
> On 2/1/24 09:40, Michael S. Tsirkin wrote:
> > On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
> > > Hi Jason,
> > > 
> > > It looks like all patches got acked by you.
> > > Any blocker to queue the series for next release?
> > > 
> > > Thanks,
> > > Maxime
> > 
> > I think it's good enough at this point. Will put it in
> > linux-next shortly.
> > 
> 
> I fetched linux-next and it seems the series is not in yet.
> Is there anything to be reworked on my side?
> 
> Thanks,
> Maxime

I am sorry I messed up. It was in a wrong branch and was not
pushed so of course it did not get tested and I kept wondering
why. I pushed it in my tree but it is too late to put it upstream
for this cycle. Assuming Linus merges my tree
with no drama, I will make an effort not to rebase my tree below them
so these patches will keep their hashes, you can use them already.

-- 
MST

On 2/1/24 09:40, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
>> Hi Jason,
>>
>> It looks like all patches got acked by you.
>> Any blocker to queue the series for next release?
>>
>> Thanks,
>> Maxime
> 
> I think it's good enough at this point. Will put it in
> linux-next shortly.
> 

Thanks Michael!