On Fri, Jan 21, 2022 at 12:52 AM Limaye, Namrata <namrata.lim...@intel.com> wrote: > > Hi, > > We are working on adding P4 support to OVS and we have recently open-sourced > the patches on the IPDK github - > https://github.com/ipdk-io/ovs/tree/ovs-with-p4 > > The architecture document that explains the changes and the upcoming feature > list is here - > > https://github.com/ipdk-io/ovs/blob/ovs-with-p4/OVS_WITH_P4_ARCH.rst > > Here is the link for the user-guide document to run OVS on host - > https://github.com/ipdk-io/ipdk/blob/main/build/ovs-with-p4_howto > > We have also built a development container that ties in all necessary pieces > and runs OVS on container. It also brings up 2 Vagrant VMs and switches > traffic between them using a simple P4 and OVS - > https://github.com/ipdk-io/ipdk/blob/main/build/README.md > > Here is the link to the code-walk video that we did last November - > https://www.youtube.com/watch?v=vhRL5SQReQs > > We still have work to do to turn these patches into a minimal set that could > be upstreamed into OVS. Once that is done, we would like to upstream these > patches to openvswitch. Please let us know your comments.
I took a quick look at this, which should not count as a full review, more commentary to help get the discussion going. First I would like to thank you for your work on getting P4 support into Open vSwitch. The P4 specifications mandate end user programmability for both control plane and data plane, so bringing this to OVS is no small feat. I need to start with some history. OpenFlow was conceived more than a decade ago and has fueled the first leg of the SDN revolution. The protocol itself is very flexible and extensible, however any additions of match operators or actions also requires changes to the data path. In this stage of the evolution changing the software data path is not sufficient as hardware offload is required to achieve the transfer speeds expected today (i.e. 100G+). The lead time of reaching consensus for new match operators, actions, hardware being designed and manufactured makes the OpenFlow extensibility impractical if not unusable. Despite this OVS's OpenFlow implementation and the likes of OVN brings state of the art 100G+ networking to the masses today, and will continue to do so for several years. What P4 promises is a framework and language which would allow reprogramming the hardware data plane behavior, targets also exist for outputting code for use in software data paths (p4-dpdk-target, eBPF etc). There will of course still be a gap between what features the P4 specification and language provides and what hardware can actually offload, but at least we have the tools to express what we want to do until the hardware catches up. So to sum up, given we will depend on hardware offload in the future, OVS would benefit from P4 support to stay relevant for the next decade, and P4 would benefit from an OVS implementation to allow the experimentation and critical production usage required for it to develop. As for the proposal itself the approach of importing large chunks of external code as sub-modules does feel a bit alien, I do however like this statement in``OVS_WITH_P4_ARCH.rst``: " Part of the development process is to prune away as much of the Stratum project as possible". I wonder if we could bring more of the infrastructure required into native OVS code? -- Frode Nordahl > Thanks > Namrata > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
