> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Tuesday, 12 November 2024 06.21 > > On Wed, 6 Nov 2024 08:46:55 +0100 > Maxime Coquelin <maxime.coque...@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.)
