p4-dev@lists.p4.org

list for questions/discussion of p4 programs and tools

View all threads

Flightplan

NS
Nik Sultana
Fri, Dec 4, 2020 5:39 PM

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

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
MB
Mihai Budiu
Fri, Dec 4, 2020 6:54 PM

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-bounces@lists.p4.org On Behalf Of Nik Sultana
Sent: Friday, December 4, 2020 9:40 AM
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflightplan.cis.upenn.edu%2Fflightplan.pdf&data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299877029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mLpZmGkMi5PjArRIiL6tmDYUO3DU%2F114llT%2F0KoO5%2Bk%3D&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&data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299877029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IUScye%2FzZYryJtOyTVNCeXzHN5cE63AAKbDgZ0%2BBZG0%3D&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&data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299887023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BTQT%2FGpzzY0Bct12kNhDePgKGRD8GRGAvBPQoR10wCc%3D&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&data=04%7C01%7Cmbudiu%40vmware.com%7C72ee10d460a04d3ecab108d8987bb02d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637427004299887023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OCF1UhKZQ%2FjSFK8j%2F8q504EmP5km9EdV9vFQxCfb3Bk%3D&reserved=0


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

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-bounces@lists.p4.org> On Behalf Of Nik Sultana Sent: Friday, December 4, 2020 9:40 AM 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://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-dev@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
H
hemant@mnkcg.com
Sat, Dec 5, 2020 7:40 PM

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

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. 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
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
H
hemant@mnkcg.com
Sat, Dec 5, 2020 10:23 PM

----Original Message-----
From: Nik Sultana nsultana@seas.upenn.edu
Sent: Saturday, December 05, 2020 3:19 PM
To: hemant@mnkcg.com
Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org;
flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu
Subject: Re: [P4-dev] Flightplan

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

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

----Original Message----- From: Nik Sultana <nsultana@seas.upenn.edu> Sent: Saturday, December 05, 2020 3:19 PM To: hemant@mnkcg.com Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org; flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu Subject: Re: [P4-dev] Flightplan >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". 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
NS
Nik Sultana
Sat, Dec 5, 2020 11:57 PM

On Sat, 05 Dec 2020, hemant@mnkcg.com wrote:

----Original Message-----
From: Nik Sultana nsultana@seas.upenn.edu
Sent: Saturday, December 05, 2020 3:19 PM
To: hemant@mnkcg.com
Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org;
flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu
Subject: Re: [P4-dev] Flightplan

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

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.

[Looping out p4-announce to spare it unnecessary traffic]

I appreciate your engagement on this and your confidence in how things
are done at present, but the focus of the above description still seems
to miss the point of what Flightplan is about. In this thread I don't
think I can do better than refer you to the Flightplan paper.

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

Hemant

On Sat, 05 Dec 2020, hemant@mnkcg.com wrote: > ----Original Message----- > From: Nik Sultana <nsultana@seas.upenn.edu> > Sent: Saturday, December 05, 2020 3:19 PM > To: hemant@mnkcg.com > Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org; > flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu > Subject: Re: [P4-dev] Flightplan > > >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". > > 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. [Looping out p4-announce to spare it unnecessary traffic] I appreciate your engagement on this and your confidence in how things are done at present, but the focus of the above description still seems to miss the point of what Flightplan is about. In this thread I don't think I can do better than refer you to the Flightplan paper. > > In summary, if I am a cloud operator or a networking product designer, I > don't see a need for Flightplan. > > Hemant
VP
Venkat Pullela
Sun, Dec 6, 2020 12:00 AM

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-dev@lists.p4.org
wrote:

----Original Message-----
From: Nik Sultana nsultana@seas.upenn.edu
Sent: Saturday, December 05, 2020 3:19 PM
To: hemant@mnkcg.com
Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org;
flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu
Subject: Re: [P4-dev] Flightplan

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

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


P4-dev mailing list
P4-dev@lists.p4.org
http://lists.p4.org/mailman/listinfo/p4-dev_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-dev@lists.p4.org> wrote: > ----Original Message----- > From: Nik Sultana <nsultana@seas.upenn.edu> > Sent: Saturday, December 05, 2020 3:19 PM > To: hemant@mnkcg.com > Cc: p4-announce@lists.p4.org; p4-dev@lists.p4.org; > flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu > Subject: Re: [P4-dev] Flightplan > > >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". > > 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 > _______________________________________________ > P4-dev mailing list > P4-dev@lists.p4.org > http://lists.p4.org/mailman/listinfo/p4-dev_lists.p4.org >
H
hemant@mnkcg.com
Sun, Dec 6, 2020 12:13 AM

From: Venkat Pullela venkat.pullela@opennets.com
Sent: Saturday, December 05, 2020 7:00 PM
To: hemant@mnkcg.com
Cc: nsultana@seas.upenn.edu; p4-announce@lists.p4.org; p4-dev@lists.p4.org; flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu
Subject: Re: [P4-dev] Flightplan

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.

<hs> For an asic with multiple pipes, the target’s P4 architecture file/definition suffices to specify P4 behavior for all pipes.  If different generations of switching ASICs from the same company are heterogeneous, each generation has a different P4 architecture file/definition.

Hemant

From: Venkat Pullela <venkat.pullela@opennets.com> Sent: Saturday, December 05, 2020 7:00 PM To: hemant@mnkcg.com Cc: nsultana@seas.upenn.edu; p4-announce@lists.p4.org; p4-dev@lists.p4.org; flightplan@seas.upenn.edu; rakeshn@seas.upenn.edu Subject: Re: [P4-dev] Flightplan 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. <hs> For an asic with multiple pipes, the target’s P4 architecture file/definition suffices to specify P4 behavior for all pipes. If different generations of switching ASICs from the same company are heterogeneous, each generation has a different P4 architecture file/definition. Hemant