RE: RFC - Tap io_uring PMD

["Varghese, Vipin" <Vipin.Varghese@amd.com>]

[Public]

Snipped
>
>
> The current tap device is slow both due to architectural choices and the overhead of
> Linux system calls. I am exploring a how to fix that but some of the choices require
> some tradeoffs. Which leads to some open questions:
>
> 1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header
>    only L3. Does anyone actually use this? It is different than what every other
>    PMD expects.
Hi Stephen, TUN interface were added in 2017 to support couple of use cases in teleco (ipsec tunneling) based on actual uses cases from user space stack. But I am not sure if anyone is using the same now.

Follow up question, is not TUN rx-tx sperate function from TAP?

Note: I am open to get this removed or separated if it is not used much.

>
> 2. The fastest way to use kernel TAP device would be to use io_uring.
>    But this was added in 5.1 kernel (2019). Rather than having conditional or
>    dual mode in DPDK tap device, perhaps there should just be a new PMD
> tap_uring?
>
> 3. Current TAP device provides hooks for several rte_flow types by playing
>    games with kernel qdisc. Does anyone really use this? Propose just not doing
>    this in new tap_uring.
>
> 4. What other features of TAP device beyond basic send/receive make sense?
>    It looks like new device could support better statistics.
>
> 5. What about Rx interrupt support?
>
> Probably the hardest part of using io_uring is figuring out how to collect completions.
> The simplest way would be to handle all completions rx and tx in the rx_burst
> function.

For the above questions from 2 to 5, I do like the idea of exploring better alternatives.