Documentation/faq/design.rst

   1 ..
   2       Licensed under the Apache License, Version 2.0 (the "License"); you may
   3       not use this file except in compliance with the License. You may obtain
   4       a copy of the License at
   5
   6           http://www.apache.org/licenses/LICENSE-2.0
   7
   8       Unless required by applicable law or agreed to in writing, software
   9       distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  10       WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
  11       License for the specific language governing permissions and limitations
  12       under the License.
  13
  14       Convention for heading levels in Open vSwitch documentation:
  15
  16       =======  Heading 0 (reserved for the title in a document)
  17       -------  Heading 1
  18       ~~~~~~~  Heading 2
  19       +++++++  Heading 3
  20       '''''''  Heading 4
  21
  22       Avoid deeper levels because they do not render well.
  23
  24 ======================
  25 Implementation Details
  26 ======================
  27
  28 Q: I hear OVS has a couple of kinds of flows.  Can you tell me about them?
  29
  30     A: Open vSwitch uses different kinds of flows for different purposes:
  31
  32     - OpenFlow flows are the most important kind of flow.  OpenFlow controllers
  33       use these flows to define a switch's policy.  OpenFlow flows support
  34       wildcards, priorities, and multiple tables.
  35
  36       When in-band control is in use, Open vSwitch sets up a few "hidden"
  37       flows, with priority higher than a controller or the user can configure,
  38       that are not visible via OpenFlow.  (See the "Controller" section of the
  39       FAQ for more information about hidden flows.)
  40
  41     - The Open vSwitch software switch implementation uses a second kind of
  42       flow internally.  These flows, called "datapath" or "kernel" flows, do
  43       not support priorities and comprise only a single table, which makes them
  44       suitable for caching.  (Like OpenFlow flows, datapath flows do support
  45       wildcarding, in Open vSwitch 1.11 and later.)  OpenFlow flows and
  46       datapath flows also support different actions and number ports
  47       differently.
  48
  49       Datapath flows are an implementation detail that is subject to change in
  50       future versions of Open vSwitch.  Even with the current version of Open
  51       vSwitch, hardware switch implementations do not necessarily use this
  52       architecture.
  53
  54 Users and controllers directly control only the OpenFlow flow table.  Open
  55 vSwitch manages the datapath flow table itself, so users should not normally be
  56 concerned with it.
  57
  58 Q: Why are there so many different ways to dump flows?
  59
  60     A: Open vSwitch has two kinds of flows (see the previous question), so it
  61     has commands with different purposes for dumping each kind of flow:
  62
  63     - ``ovs-ofctl dump-flows <br>`` dumps OpenFlow flows, excluding hidden
  64       flows.  This is the most commonly useful form of flow dump.  (Unlike the
  65       other commands, this should work with any OpenFlow switch, not just Open
  66       vSwitch.)
  67
  68     - ``ovs-appctl bridge/dump-flows <br>`` dumps OpenFlow flows, including
  69       hidden flows.  This is occasionally useful for troubleshooting suspected
  70       issues with in-band control.
  71
  72     - ``ovs-dpctl dump-flows [dp]`` dumps the datapath flow table entries for a
  73       Linux kernel-based datapath.  In Open vSwitch 1.10 and later,
  74       ovs-vswitchd merges multiple switches into a single datapath, so it will
  75       show all the flows on all your kernel-based switches.  This command can
  76       occasionally be useful for debugging.
  77
  78     - ``ovs-appctl dpif/dump-flows <br>``, new in Open vSwitch 1.10, dumps
  79       datapath flows for only the specified bridge, regardless of the type.
  80
  81 Q: How does multicast snooping works with VLANs?
  82
  83     A: Open vSwitch maintains snooping tables for each VLAN.
  84
  85 Q: Can OVS populate the kernel flow table in advance instead of in reaction to
  86 packets?
  87
  88     A: No.  There are several reasons:
  89
  90     - Kernel flows are not as sophisticated as OpenFlow flows, which means that
  91       some OpenFlow policies could require a large number of kernel flows.  The
  92       "conjunctive match" feature is an extreme example: the number of kernel
  93       flows it requires is the product of the number of flows in each
  94       dimension.
  95
  96     - With multiple OpenFlow flow tables and simple sets of actions, the number
  97       of kernel flows required can be as large as the product of the number of
  98       flows in each dimension.  With more sophisticated actions, the number of
  99       kernel flows could be even larger.
 100
 101     - Open vSwitch is designed so that any version of OVS userspace
 102       interoperates with any version of the OVS kernel module.  This forward
 103       and backward compatibility requires that userspace observe how the kernel
 104       module parses received packets.  This is only possible in a
 105       straightforward way when userspace adds kernel flows in reaction to
 106       received packets.
 107
 108     For more relevant information on the architecture of Open vSwitch, please
 109     read "The Design and Implementation of Open vSwitch", published in USENIX
 110     NSDI 2015.
 111
 112 Q: How many packets does OVS buffer?
 113
 114     A: Open vSwitch fast path packet processing uses a "run to completion"
 115     model in which every packet is completely handled in a single pass.
 116     Therefore, in the common case where a packet just passes through the fast
 117     path, Open vSwitch does not buffer packets itself.  The operating system
 118     and the network drivers involved in receiving and later in transmitting the
 119     packet do often include buffering.  Open vSwitch is only a middleman
 120     between these and does not have direct access or influence over their
 121     buffers.
 122
 123     Outside the common case, Open vSwitch does sometimes buffer packets.  When
 124     the OVS fast path processes a packet that does not match any of the flows
 125     in its megaflow cache, it passes that packet to the Open vSwitch slow path.
 126     This procedure queues a copy of the packet to the Open vSwitch userspace
 127     which processes it and, if necessary, passes it back to the kernel module.
 128     Queuing the packet to userspace as part of this process involves buffering.
 129     (Going the opposite direction does not, because the kernel actually
 130     processes the request synchronously.)  A few other exceptional cases also
 131     queue packets to userspace for processing; most of these are due to
 132     OpenFlow actions that the fast path cannot handle and that must therefore
 133     be handled by the slow path instead.
 134
 135     OpenFlow also has a concept of packet buffering.  When an OpenFlow switch
 136     sends a packet to a controller, it may opt to retain a copy of the packet
 137     in an OpenFlow "packet buffer".  Later, if the controller wants to tell the
 138     switch to forward a copy of that packet, it can refer to the packet through
 139     its assigned buffer, instead of sending the whole packet back to the
 140     switch, thereby saving bandwidth in the OpenFlow control channel.  Before
 141     Open vSwitch 2.7, OVS implemented such buffering; Open vSwitch 2.7 and
 142     later do not.