PANDA: Zabiplane reboot and XDP Hints

PANDA: Zabiplane reboot and XDP Hints

[Tom Herbert]

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

PANDA: Zabiplane reboot and XDP Hints

[Alexander Lobakin]

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