We use a dpif implementation (based very much on dpif-netdev) but have also strongly considered writing our own ofproto. So I would agree that keeping the ofproto layer would be a good thing. And keeping it in such a way as to make it possible to write a new one!
OpenSwitch is one project that have written their own ofproto (last time I looked) but they have a slightly different use of Open vSwitch anyway (they focus more on the reconfigure code than on doing anything with OpenFlow rules. Tony On Sat, Mar 18, 2017 at 7:44 PM, Stephen Bailey <[email protected]> wrote: > Yes, they implement of-proto providers. > > I guess we've seen a disjoint set of switches, which is not necessarily > surprising :-). > > What's the expectation for e.g. a P4 switch? It seems the most natural > mapping is an OpenFlow-style pipeline (versus dpif). > > Admittedly, there are many other OpenFlow agents beside OVS (e.g. the P4 > OpenFlow agent, etc etc), it just seems OVS is particularly important in > open source networking (especially data center) and maintaining a distinct > OpenFlow layer beneficial. > > That said, of course I wouldn't arm wrestle you over it if nobody else cares > :-). > > Steph > > > On Fri, Mar 17, 2017 at 11:24 PM, Ben Pfaff <[email protected]> wrote: >> >> Do you mean that these implementations have their own ofproto provider >> implementations, that is, that they do not use ofproto-dpif and instead >> implement a different ofproto_class as defined in >> ofproto/ofproto-provider.h? That indeed would be news to me. All of >> the switches that I am aware of instead implement a dpif provider, as >> defined in lib/dpif-provider.h. The dpif provider interface in that >> file is valuable and not going away. >> >> On Fri, Mar 17, 2017 at 09:33:26AM +0800, Stephen Bailey wrote: >> > I think it would be unfortunate to drop ofproto. >> > >> > I can't speak to Allied's implementation, but all switch implementations >> > I >> > am aware of use ofproto, including several I have worked on. >> > >> > These implementations don't tend to get upstreamed. However, I think >> > OVS >> > plays quite an important role as an (the?) OpenFlow reference >> > implementation. >> > >> > I'm not sure if we could accomplish it but if it would help provide some >> > mass against ofproto, perhaps we could get an implemention or two >> > upstreamed? >> > >> > Steph >> > >> > >> > On Mar 16, 2017 08:58, "Ben Pfaff" <[email protected]> wrote: >> > >> > > On Tue, Mar 14, 2017 at 05:26:28PM +1300, Tony van der Peet wrote: >> > > > >On Fri, Mar 10, 2017 at 11:14:55AM +0530, Shravan S K wrote: >> > > > >> We are looking to buy a few OpenFlow-enabled switches. What >> > > advantages can >> > > > >> be achieved by a hardware switch that also supports OVS? >> > > > >> And can a hardware openflow L2 switch perform L3,L4 based >> > > > >> openflow >> > > > >> forwarding - can I inspect L3,L4 layers and take a decision based >> > > > >> on >> > > them ? >> > > > > >> > > > >It's hard to tell. No one ever comes to us and says that they base >> > > > >their switch on OVS. You have to guess. >> > > > >> > > > For the record, Allied Telesis have a range of switches that use >> > > > OVS. >> > > >> > > Good to know. Do these switches implement a dpif provider or an >> > > ofproto >> > > provider? We're talking about dropping the ofproto provider layer, so >> > > it's an important question. >> > > _______________________________________________ >> > > discuss mailing list >> > > [email protected] >> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > > > > _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
