RFC - Tap io_uring PMD

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, 12 November 2024 06.21
> 
> On Wed, 6 Nov 2024 08:46:55 +0100
> Maxime Coquelin <maxime.coquelin at redhat.com> wrote:
> >
> > Why not just use Virtio-user PMD with Vhost-kernel backend [0]?
> > Are there any missing features that io_uring can address?
> >
> > Regards,
> > Maxime
> >
> > [0]:
> http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html
> >
> 
> Yes, I looked at that but:
>   - virtio user ends up with a busy kernel thread which is not
> acceptable
>     in SOC environment where all resources are locked down. In the SOC
> I was working
>     on DPDK was limited to 4 polling isolated CPU's and 1 sleeping main
> thread.
>     The rest of the CPU resources were hard constrained by cgroups. The
> virtio user
>     thread was a problem.

I suppose the Kernel needs to schedule CPU resources to process the packets at some point anyway.
So how does the ioring driver improve the situation with the virtio-user thread? I.e. what's the difference in the way the Kernel handles these two types of drivers?

And a slightly related question: Are there any differences in throughput, latency or other performance metrics? (At very high bandwidth, scheduling latency matters; the "latency" parameter of the BDP becomes dominant.)

Overall, I'm trying to figure out when to use the virtio-user PMD, and when to use the ioring PMD.
Eventually, this should be described in the driver documentation or a user guide.

> 
>   - virtio user device is not persistent. If DPDK is being used a
> dataplane, need to
>     be able to quickly restart and not disturb applications and routing
> in the kernel
>     while the tap device is unavailable.  I.e having device present but
> in no carrier
>     state is better than having to teach applications about hot plug or
> play around
>     with multiple addresses on loopback device (which is what Cisco
> routers do).

virtio-user device persistence can probably be achieved in some other way.
(E.g. a persistent user space daemon could be used as a middle man for allocation. Just an idea; probably better solutions are available, if given more brain cycles.)