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