p4-announce@lists.p4.org

Announcements for P4.org

View all threads

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

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 >