Re: RFC - Tap io_uring PMD

[Igor Gutorov <igootorov@gmail.com>]

On Wed, Nov 6, 2024 at 2:54 AM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, 6 November 2024 00.26
> >
> > On Wed, 6 Nov 2024 00:22:19 +0100
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > From what I understand, the TAP io_uring PMD only supports one RX
> > queue per port and one TX queue per port (i.e. per TAP interface). We
> > can take advantage of this:
> >
> >
> > No kernel tap support multi queue and we need to use that.
>
> Maybe I got it wrong then... I thought you said fanout (of kernel->TAP packets) would affect all fds associated with the TAP interface.
> How can the application then use multiple queues?
>
> Another thing is:
> For which purposes do applications need multi queue support for TAP, considering the interface is for management traffic only?

I've previously used net_pcap as well as net_af_packet PMDs for
debugging/testing and even benchmarking purposes. I'd set up a
software interface, then feed test traffic via `tcpreplay`.
Some of the limitations I've encountered are:

- net_af_packet does not report received/missed packet counters
- net_pcap does not have multi queue support (AFAIK)

As an example, non symmetric RSS configurations may cause 2-way TCP
packets to be steered to different queues. If your application is a
worker-per-queue application with no shared state, you might want to
have these packets to be steered to the same queue instead. Without
multi queue, you can't easily test against scenarios like that.

Though, as you've said, if TAP is for management only, perhaps I was
trying to use the wrong tool for the wrong job.
In the end, I ended up getting a real two port NIC (feeding traffic
from one port to the other) because software PMDs are not similar
enough to the actual hardware.

--
Igor