On Sat, 05 Dec 2020, firstname.lastname@example.org wrote:
Thanks for sharing. Good start.
However, when I am designing a hardware product for networking, I know well
what the switching asic can or cannot do.
I take your point, but Flightplan is not intended for people designing a
hardware product. It's intended to solve a different problem than that
described above and elaborated in the rest of your message.
Flightplan's intended for people writing software to go into a
heterogeneous programmable network.
Furthermore, this set of people includes those who don't necessarily
know (or should be made to care about) how the sausage gets made: they
want to write in-network software to solve a business problem without
getting bogged down by toolchain and platform arcana.
Though some, me included, certainly enjoy a high level of detail when
designing network systems, part of the research value pursued in
Flightplan involved seeing how much effort can be automated away in the
case of distributing dataplane programs while bounding the impact this
would have on quality of the outcome. Among other things, this would
avoid forcing software writers into a development churn if part of the
network were to be upgraded to use different hardware from a different
vendor. There are parallels here with portability of software across
computer systems that was grappled with in decades past, but it also
brings into sharper focus the new challenges presented when writing
"software for the network".
For example, 5G cellular UPF
stores up to 65k packets. A switching asic running at 12 Tbps can't store
such data. One could design a switch that uses an asic and also an FPGA
that is used to store packets. Or the switch sends packets to store to an
external server. Likewise, for crypto, a Cavium Nitrox asic is used in the
switch. In summary, during product design, I know what runs on switching
asic vs. FPGA vs. an external server. I don't need automated tools for such
as flightplan for such high-level design and I can ship my product.
Next, there is a problem in switching asics that code doesn't fit. A good
p4 complier such as Barefoot/Intel lets me know what doesn't fit. The kind
of p4 code changes I made to fit are hard to automate, especially if the
switch changes to using a Cisco ONE asic. It is also known at design time
that I won't run compress/decompress or FEC in switching asic.
There is an Intel white paper out there which shows a UPF running at 1.2/1.4
Tbps on Intel servers using smartNIC. Again, with the P4 code for a UPF,
just manual inspection of the code tells one that UPF's 6-tuple lookup on
every packet runs in the FPGA on smartNIC - this is what the paper has done.
Other UPF code runs on the server cpu and the code uses Cisco VPP.
For redundancy, networks either use two switches or the CLOS topology. BFD
is also used to detect link failure in data plane.
From: P4-dev email@example.com On Behalf Of Nik Sultana
Sent: Friday, December 04, 2020 12:40 PM
To: firstname.lastname@example.org; email@example.com
Cc: Flightplan mailing list firstname.lastname@example.org; Rakesh Nagda
Subject: [P4-dev] Flightplan
Hi all, I wanted to share with the wider P4 community the Flightplan
(https://flightplan.cis.upenn.edu/flightplan.pdf) system release which
includes new P4 code, adapted third-party P4 code, network functions, and a
P4 toolchain extension to split and allocate P4 programs:
The repo also contains documentation, reproducibility aids, test suites, an
experiment platform, results, etc: https://github.com/eniac/Flightplan
All is released under a permissive open-source license.
Flightplan was the labour of many, as visible in the paper+repo. With
regards to the system's release, Rakesh (cc'd) played a key role in
meticulously preparing and documenting important parts of the system. He can
find his way around clumps of unfamiliar + inter-related codebases with
ease, and is enthusiastic about working on P4 in industry after he
graduates. If you need talent then do reach out to him.
P4-dev mailing list