PANDA: Zabiplane reboot and XDP Hints

[Alexander Lobakin <alexandr.lobakin@intel.com>]

From: Tom Herbert <tom@sipanda.io>
Date: Fri, 17 Sep 2021 11:35:41 -0700

> Hello,
> 
> As you may recall, there was some initial work a while back on the
> Zabiplane project as a ubiquitous, high performance networking
> dataplane. For various reasons, that effort really didn't go very far,
> however the intent and the principles behind it were correct and the
> need in the industry for a ubiquitous, programmable, high performance,
> and easy-to-use dataplane still persists. To that end we propose PANDA
> as an open source project that achieves the goals but also addresses
> the problems Zabiplane had.
> 
> PANDA ties in well with XDP hints. Where XDP hints is about defining
> the kernel/driver interfaces to allow devices to provide metadata
> about packets, PANDA is the model allowing the stack to _program_ the
> device to provide exactly the information it wants as XDP hints. This
> programming includes not only the types of extracted metadata, but
> also describes _how_ to programmatically produce the metadata. In
> particular, PANDA is a common model for programmable parsers with
> metadata extraction which is the device mechanism for things like XDP
> Hints (pretty much every hardware vendor is developing hardware
> parsers, PANDA would be the common means to get value from that).
> 
> This programming is done explicitly through the stack as a form of
> offload-- per the HW/SW offload equivalence principle, the kernel
> stack and the device would run the exact same source code (hence why
> P4 doesn't work). The net effect of this is that the device is now
> operating under the direct auspices of the stack to the extent that
> that stack boundary is extended _into_ the device. This means the
> stack can now trust what the device is doing since it has full
> visibility and control. In this way, we can go beyond just getting
> simple "hints" and get pertinent operational information to the stack
> from the device. For example, a programmable device should be able to
> perform all the stateless processing for a TCP/IP packet such that the
> stack could jump directly to TCP receive processing function
> (borrowing from the goal of TXDP). As another example, a truly useful
> LRO could be programmed in the device that would basically run the
> same code as GRO and be equally extensible.
> 
> If you are interested, please join the discussion list
> PANDA.groups.io, or if you have any questions you can contact me

Joined, thanks!

> directly. Also, unlike Zabiplane, we are starting the PANDA effort
> with contributions as opposed to manufacturing an open source project
> from thin air (code for the PANDA parser is
> https://github.com/panda-net/panda and we have also posted some RFC
> patches on netdev for flower2 that uses PANDA) .
> 
> Thanks,
> Tom

Al