X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=PORTING;h=5281d50cf0a37583ace4ea210da17984694d4625;hb=refs%2Fheads%2Fbranch-1.5;hp=09458ee4ccbce90f544615188b55df400ea08ae6;hpb=b2fda3effc787f265b5ad5dfa967ac00627bd075;p=sliver-openvswitch.git diff --git a/PORTING b/PORTING index 09458ee4c..5281d50cf 100644 --- a/PORTING +++ b/PORTING @@ -53,7 +53,7 @@ these components should not need to be modified as part of a port: - "ofproto" is the Open vSwitch library, in ofproto/, that implements an OpenFlow switch. It talks to OpenFlow controllers - over the network and to switch hardware or software to an + over the network and to switch hardware or software through an "ofproto provider", explained further below. - "netdev" is the Open vSwitch library, in lib/netdev.c, that @@ -146,7 +146,11 @@ depends on a few different factors: other features. An ofproto provider has to provide its own implementations, if the hardware can support them at all. - * A dpif provider is usually easier to implement. + * A dpif provider is usually easier to implement, but most + appropriate for software switching. It "explodes" wildcard + rules into exact-match entries. This allows fast hash lookups + in software, but makes inefficient use of TCAMs in hardware + that support wildcarding. The following sections describe how to implement each kind of port. @@ -156,9 +160,9 @@ ofproto Providers An "ofproto provider" is what ofproto uses to directly monitor and control an OpenFlow-capable switch. struct ofproto_class, in -ofproto/private.h, defines the interfaces to implement a ofproto -provider for new hardware or software. That structure contains many -function pointers, each of which has a comment that is meant to +ofproto/ofproto-provider.h, defines the interfaces to implement an +ofproto provider for new hardware or software. That structure contains +many function pointers, each of which has a comment that is meant to describe its behavior in detail. If the requirements are unclear, please report this as a bug. @@ -192,19 +196,19 @@ into the Open vSwitch architecture: | | ovs-vswitchd |<-->ovsdb-server | +-------------------+ | | ofproto |<-->OpenFlow controllers - | +--------+-+--------+ - | | netdev | |ofproto-| - userspace | +--------+ | dpif | - | | netdev | +--------+ - | |provider| | dpif | - | +---||---+ +--------+ - | || | dpif | - | || |provider| - |_ || +---||---+ - || || - _ +---||-----+---||---+ - | | |datapath| - kernel | | +--------+ + | +--------+-+--------+ _ + | | netdev | |ofproto-| | + userspace | +--------+ | dpif | | + | | netdev | +--------+ | + | |provider| | dpif | | + | +---||---+ +--------+ | + | || | dpif | | implementation of + | || |provider| | ofproto provider + |_ || +---||---+ | + || || | + _ +---||-----+---||---+ | + | | |datapath| | + kernel | | +--------+ _| | | | |_ +--------||---------+ || @@ -241,11 +245,6 @@ ovs_be64 as fixed-width types in network byte order. Each of the latter is equivalent to the one of the former, but the difference in name makes the intended use obvious. -ovs-vswitchd is the most sophisticated of ofproto's clients, but -ofproto can have other clients as well. ovs-openflowd, in the -utilities directory, is much simpler than ovs-vswitchd. It may be -easier to initially bring up ovs-openflowd as part of a port. - lib/entropy.c assumes that it can obtain high-quality random number seeds at startup by reading from /dev/urandom. You will need to modify it if this is not true on your platform. @@ -254,6 +253,51 @@ vswitchd/system-stats.c only knows how to obtain some statistics on Linux. Optionally you may implement them for your platform as well. +Why OVS Does Not Support Hybrid Providers +----------------------------------------- + +The "Porting Strategies" section above describes the "ofproto +provider" and "dpif provider" porting strategies. Only an ofproto +provider can take advantage of hardware TCAM support, and only a dpif +provider can take advantage of the OVS built-in implementations of +various features. It is therefore tempting to suggest a hybrid +approach that shares the advantages of both strategies. + +However, Open vSwitch does not support a hybrid approach. Doing so +may be possible, with a significant amount of extra development work, +but it does not yet seem worthwhile, for the reasons explained below. + +First, user surprise is likely when a switch supports a feature only +with a high performance penalty. For example, one user questioned why +adding a particular OpenFlow action to a flow caused a 1,058x slowdown +on a hardware OpenFlow implementation [1]. The action required the +flow to be implemented in software. + +Given that implementing a flow in software on the slow management CPU +of a hardware switch causes a major slowdown, software-implemented +flows would only make sense for very low-volume traffic. But many of +the features built into the OVS software switch implementation would +need to apply to every flow to be useful. There is no value, for +example, in applying bonding or 802.1Q VLAN support only to low-volume +traffic. + +Besides supporting features of OpenFlow actions, a hybrid approach +could also support forms of matching not supported by particular +switching hardware, by sending all packets that might match a rule to +software. But again this can cause an unacceptable slowdown by +forcing bulk traffic through software in the hardware switch's slow +management CPU. Consider, for example, a hardware switch that can +match on the IPv6 Ethernet type but not on fields in IPv6 headers. An +OpenFlow table that matched on the IPv6 Ethernet type would perform +well, but adding a rule that matched only UDPv6 would force every IPv6 +packet to software, slowing down not just UDPv6 but all IPv6 +processing. + +[1] Aaron Rosen, "Modify packet fields extremely slow", + openflow-discuss mailing list, June 26, 2011, archived at + https://mailman.stanford.edu/pipermail/openflow-discuss/2011-June/002386.html. + + Questions ---------