[P4-announce] Flightplan

1 view
Skip to first unread message

Nik Sultana

unread,
Dec 4, 2020, 12:39:41 PM12/4/20
to p4-an...@lists.p4.org
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: https://flightplan.cis.upenn.edu/

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.

--
www.seas.upenn.edu/~nsultana

Mihai Budiu

unread,
Dec 4, 2020, 1:54:36 PM12/4/20
to p4-an...@lists.p4.org
This is very interesting, thank you for your contributions.
Could you consider writing a blog post for the ONF P4 blog about this project?
https://opennetworking.org/category/p4/

Mihai


-----Original Message-----
From: P4-dev <p4-dev-...@lists.p4.org> On Behalf Of Nik Sultana
Sent: Friday, December 4, 2020 9:40 AM
To: p4-an...@lists.p4.org; p4-...@lists.p4.org
Cc: Flightplan mailing list <fligh...@seas.upenn.edu>; Rakesh Nagda <rak...@seas.upenn.edu>
Subject: [P4-dev] Flightplan

Hi all, I wanted to share with the wider P4 community the Flightplan (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflightplan.cis.upenn.edu%2Fflightplan.pdf&amp;data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299877029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=mLpZmGkMi5PjArRIiL6tmDYUO3DU%2F114llT%2F0KoO5%2Bk%3D&amp;reserved=0) 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: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflightplan.cis.upenn.edu%2F&amp;data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299877029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IUScye%2FzZYryJtOyTVNCeXzHN5cE63AAKbDgZ0%2BBZG0%3D&amp;reserved=0

The repo also contains documentation, reproducibility aids, test suites, an experiment platform, results, etc: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feniac%2FFlightplan&amp;data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299887023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BTQT%2FGpzzY0Bct12kNhDePgKGRD8GRGAvBPQoR10wCc%3D&amp;reserved=0


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.

--
https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.seas.upenn.edu%2F~nsultana&amp;data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299887023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=OCF1UhKZQ%2FjSFK8j%2F8q504EmP5km9EdV9vFQxCfb3Bk%3D&amp;reserved=0

_______________________________________________
P4-dev mailing list
P4-...@lists.p4.org
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.p4.org%2Fmailman%2Flistinfo%2Fp4-dev_lists.p4.org&amp;data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299887023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XVU48uCMihEMi1qUXBavIcl%2FBggHp21FKq8p8%2FRE9Ek%3D&amp;reserved=0

Nik Sultana

unread,
Dec 5, 2020, 3:18:51 PM12/5/20
to p4-an...@lists.p4.org
On Sat, 05 Dec 2020, hem...@mnkcg.com 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.
>
> Hemant


>
> -----Original Message-----
> From: P4-dev <p4-dev-...@lists.p4.org> On Behalf Of Nik Sultana
> Sent: Friday, December 04, 2020 12:40 PM
> To: p4-an...@lists.p4.org; p4-...@lists.p4.org
> Cc: Flightplan mailing list <fligh...@seas.upenn.edu>; Rakesh Nagda
> <rak...@seas.upenn.edu>
> 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:

> https://flightplan.cis.upenn.edu/


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

> www.seas.upenn.edu/~nsultana


>
> _______________________________________________
> P4-dev mailing list
> P4-...@lists.p4.org

> http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org

--
www.seas.upenn.edu/~nsultana

Venkat Pullela

unread,
Dec 5, 2020, 7:00:25 PM12/5/20
to p4-an...@lists.p4.org
Great work.
Agreed this can't be a solution to all use cases, but this is very useful for dealing with heterogeneous systems. The examples taken in the paper may not convey the full potential and I am sure this will evolve as important use cases get prioritized.
Even within a switching ASIC there are multiple pipes, and it is possible some pipes are oversubscribed and others are not. Even different generations of switching ASICs from the same company can create heterogeneity. 

--
Venkat Pullela
OpenNets

On Sat, Dec 5, 2020 at 2:24 PM Hemant Singh via P4-dev <p4-...@lists.p4.org> wrote:
Cloud data center operators such as Amazon AWS , Google Cloud, Microsoft
Azure)  do not run this way.  At least AWS and Azure use heterogeneous
network nodes in Annapurna cpu and FPGA on smartNIC respectively, switches,
and server machines.  Both AWS and Azure run SDN in smartNIC.  Networking
firmware for each node is pre-determined.  Even if the operator switches
from using Verilog or C to programming in P4, the pre-determined firmware of
each node (from any vendor) does not change.  If firmware is upgraded, the
upgrade is not a fork-lift upgrade that suddenly moves encryption from
smartNIC to the switch or server.  So all the operator has to do is use a
tool that reuses/merges P4 programs.  Such tools exists from Cisco, my
company (https://mnkcg.com) and Mellanox switch SDK. 

In summary, if I am a cloud operator or a networking product designer, I
don't see a need for Flightplan.

Hemant
Reply all
Reply to author
Forward
0 new messages