Re: RFC - Tap io_uring PMD

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 6 Nov 2024 03:52:51 +0300
Igor Gutorov <igootorov@gmail.com> wrote:

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

DPDK interactions with kernel devices is complicated, there are overlapping
drivers:
	- TAP  - uses Linux tap device
	- PCAP - uses libpcap which ends up using af_packet
        - AF_PACKET - uses af_packet
        - AF_XDP - uses XDP
        - Virtio user - relies on vhost in kernel

There are lots of differences in performance, control usage, and other
details between these.

The proposal is to do simpler faster version of the TAP.
Will also do some comparisons and detail (maybe presentation or document)
on all the others later.

So far, have a basic driver that does setup and basic management operations;
still working on details of the ring stuff.