Merge branch 'mainstream'

[sliver-openvswitch.git] / FAQ

diff --git a/FAQ b/FAQ
index e6e649f..c6ccbd1 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -1122,7 +1122,8 @@ A: Before version 1.11, Open vSwitch did not support MPLS.  That is,
    for MPLS.  With the userspace datapath only, these versions can
    match, push, or pop a single MPLS label, but they still cannot look
    past MPLS labels (even after popping them) into the encapsulated
    for MPLS.  With the userspace datapath only, these versions can
    match, push, or pop a single MPLS label, but they still cannot look
    past MPLS labels (even after popping them) into the encapsulated

-   packet.  Kernel datapath support is unchanged from earlier verions.
+   packet.  Kernel datapath support is unchanged from earlier
+   versions.

 
    Open vSwitch version 2.2 will be able to match, push, or pop up to
    3 MPLS labels.  Looking past MPLS labels into the encapsulated
 
    Open vSwitch version 2.2 will be able to match, push, or pop up to
    3 MPLS labels.  Looking past MPLS labels into the encapsulated


@@ -1402,9 +1403,9 @@ A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
    even be convenient, e.g. it is often the desired behavior in a flow
    that forwards a packet to several ports ("floods" the packet).
 
    even be convenient, e.g. it is often the desired behavior in a flow
    that forwards a packet to several ports ("floods" the packet).
 

-   Sometimes one really needs to send a packet out its ingress port.
-   In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is
-   expressed as just "in_port", e.g.:
+   Sometimes one really needs to send a packet out its ingress port
+   ("hairpin"). In this case, output to OFPP_IN_PORT, which in
+   ovs-ofctl syntax is expressed as just "in_port", e.g.:

 
        ovs-ofctl add-flow br0 in_port=2,actions=in_port
 
 
        ovs-ofctl add-flow br0 in_port=2,actions=in_port
 


@@ -1474,6 +1475,23 @@ A: These flows drop the ARP packets that IP hosts use to establish IP
       priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
       priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
 
       priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
       priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
 

+
+Development
+-----------
+
+Q: How do I implement a new OpenFlow message?
+
+A: Add your new message to "enum ofpraw" and "enum ofptype" in
+   lib/ofp-msgs.h, following the existing pattern.  Then recompile and
+   fix all of the new warnings, implementing new functionality for the
+   new message as needed.  (If you configure with --enable-Werror, as
+   described in INSTALL, then it is impossible to miss any warnings.)
+
+   If you need to add an OpenFlow vendor extension message for a
+   vendor that doesn't yet have any extension messages, then you will
+   also need to edit build-aux/extract-ofp-msgs.
+
+

 Contact 
 -------
 
 Contact 
 -------