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
On Sat, Dec 5, 2020 at 2:24 PM Hemant Singh via P4-dev email@example.com
From: Nik Sultana firstname.lastname@example.org
Sent: Saturday, December 05, 2020 3:19 PM
Cc: email@example.com; firstname.lastname@example.org;
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
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
grappled with in decades past, but it also brings into sharper focus the
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
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.
P4-dev mailing list