4 new exciting talks have been accepted by the PC

1) Alex Markuze takes another crack at dealing with socket overhead. Most solutions overcome the overhead by moving the processing to user space via zero copy. Alex will describe a new approach called MAIO with kernel/userspace shared memory pages from a dedicated allocator. Unlike DPDK, the kernel tcp stack is used by means of dedicated rx/tx kernel threads+kernel tcp sockets.

2) Jesse Brandeburg and Brett Creeley describe PowerMAN, a user space tool for Dynamic Interface Power Management. NIC hardware buffering is not keeping up with increasing speeds. Achieving maximum performance implies tuning the NICs which typically comes at the cost of power consumption. PowerMAN addresses these issues. Jesse and Brett are looking for feedback: Should this tool move in-kernel or stay in user-space? Much of the work may be more appropriate for the kernel scheduler to be involved.

3) Boris Pismenny, Yoray Zack, Ben Ben-Ishay and Or Gerlitz will discuss work on Autonomous NVMe-TCP offload. Traditional approaches to offloading NVMe-TCP require offloading a lot of L4 functionality: TCP, IP, routing, QoS, NAT, firewall, etc Not only is this undesirable given the complexity - but is also easily mitigated for bulk storage using batching as demonstrated in 0x14 talk[1]. Boris et al present how to offload CPU-intensive operations that cannot be optimized away using batching or clever software engineering: copy and CRC independent of L4 functionality.

4) Nabil Bitar and Jamal Hadi Salim describe their performance work on Linux ACL subsytems. Their work was motivated by lack of existing extensive comparison that fairly evaluate both _forwarding_ and _host_ workloads. The comparison is modeled using a widely deployed iptables use case. They look at: Iptables(with and without conntracking), IPtables with IPSet (with and without conntracking), XDP/ebpf, tc/ebpf, and tc/flower. They analyse both control path as well as data path performance under a variety of conditions. They are hoping their experience will help others in the community make decisions as to what approach to take under given circumstances. They are hoping as well to get community feedback and evolve the work further.

cheers, jamal

[1] https://netdevconf.info/0x14/session.html?talk-NVMe-over-TCP-is-not-NVMe-ove...