p4-announce@lists.p4.org

Announcements for P4.org

View all threads

Re: [P4-announce] [P4-dev] Flightplan

NS
Nik Sultana
Sat, Dec 5, 2020 8:18 PM

On Sat, 05 Dec 2020, hemant@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-bounces@lists.p4.org On Behalf Of Nik Sultana
Sent: Friday, December 04, 2020 12:40 PM
To: p4-announce@lists.p4.org; p4-dev@lists.p4.org
Cc: Flightplan mailing list flightplan@seas.upenn.edu; Rakesh Nagda
rakeshn@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-dev@lists.p4.org
http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org

On Sat, 05 Dec 2020, hemant@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-bounces@lists.p4.org> On Behalf Of Nik Sultana > Sent: Friday, December 04, 2020 12:40 PM > To: p4-announce@lists.p4.org; p4-dev@lists.p4.org > Cc: Flightplan mailing list <flightplan@seas.upenn.edu>; Rakesh Nagda > <rakeshn@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-dev@lists.p4.org > http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org -- www.seas.upenn.edu/~nsultana