[ovs-dev] [PATCH ovn v3 01/10] ovn-sb.xml: Revise description of "actions" to match my current thoughts.
Ben Pfaff
blp at nicira.com
Fri Apr 24 22:34:51 UTC 2015
This is what I'm in the midst of implementing, and what ovn-northd uses.
Reported-by: Justin Pettit <jpettit at nicira.com>
Signed-off-by: Ben Pfaff <blp at nicira.com>
---
ovn/northd/ovn-northd.c | 11 ++----
ovn/ovn-sb.xml | 89 ++++++++++++++++++++---------------------------
2 files changed, 40 insertions(+), 60 deletions(-)
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 8a09ce1..4f64d49 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -415,7 +415,7 @@ build_pipeline(struct northd_context *ctx)
/* Table 3: Egress port security. */
NBREC_LOGICAL_PORT_FOR_EACH (lport, ctx->ovnnb_idl) {
- struct ds match, actions;
+ struct ds match;
ds_init(&match);
ds_put_cstr(&match, "outport == ");
@@ -424,15 +424,8 @@ build_pipeline(struct northd_context *ctx)
lport->port_security, lport->n_port_security,
&match);
- ds_init(&actions);
- ds_put_cstr(&actions, "output(");
- json_string_escape(lport->name, &actions);
- ds_put_cstr(&actions, ");");
-
- pipeline_add(&pc, lport->lswitch, 3, 50,
- ds_cstr(&match), ds_cstr(&actions));
+ pipeline_add(&pc, lport->lswitch, 3, 50, ds_cstr(&match), "output;");
- ds_destroy(&actions);
ds_destroy(&match);
}
diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index be876b8..bc648e1 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -552,84 +552,71 @@
<column name="actions">
<p>
- Below, a <var>value</var> is either a <var>constant</var> or a
- <var>field</var>. The following actions seem most likely to be useful:
+ Logical datapath actions, to be executed when the logical flow
+ represented by this row is the highest-priority match.
</p>
- <dl>
- <dt><code>drop;</code></dt>
- <dd>syntactic sugar for no actions</dd>
+ <p>
+ Actions share lexical syntax with the <ref column="match"/> column. An
+ empty set of actions (or one that contains just white space or
+ comments), or a set of actions that consists of just
+ <code>drop;</code>, causes the matched packets to be dropped.
+ Otherwise, the column should contain a sequence of actions, each
+ terminated by a semicolon.
+ </p>
- <dt><code>output(<var>value</var>);</code></dt>
- <dd>output to port, except that output to the ingress port is
- implicitly dropped</dd>
+ <p>
+ The following actions will be initially supported:
+ </p>
- <dt><code>broadcast;</code></dt>
- <dd>output to every logical port except ingress port</dd>
+ <dl>
+ <dt><code>output;</code></dt>
+ <dd>
+ Outputs the packet to the logical port current designated by
+ <code>outport</code>. Output to the ingress port is implicitly
+ dropped, that is, <code>output</code> becomes a no-op if
+ <code>outport</code> == <code>inport</code>.
+ </dd>
<dt><code>resubmit;</code></dt>
- <dd>execute next logical datapath table as subroutine</dd>
+ <dd>
+ Executes the next logical datapath table as a subroutine.
+ </dd>
- <dt><code>set(<var>field</var>=<var>value</var>);</code></dt>
- <dd>set data or metadata field, or copy between fields</dd>
+ <dt><code><var>field</var> = <var>constant</var>;</code></dt>
+ <dd>
+ Sets data or metadata field <var>field</var> to constant value
+ <var>constant</var>.
+ </dd>
</dl>
<p>
- Following are not well thought out:
+ The following actions will likely be useful later, but they have not
+ been thought out carefully.
</p>
<dl>
+ <dt><code><var>field1</var> = <var>field2</var>;</code></dt>
+ <dd>
+ Extends the assignment action to allow copying between fields.
+ </dd>
+
<dt><code>learn</code></dt>
<dt><code>conntrack</code></dt>
- <dt><code>with(<var>field</var>=<var>value</var>) { <var>action</var>, </code>...<code> }</code></dt>
- <dd>execute <var>actions</var> with temporary changes to <var>fields</var></dd>
-
- <dt><code>dec_ttl { <var>action</var>, </code>...<code> } { <var>action</var>; </code>...<code>}</code></dt>
+ <dt><code>dec_ttl { <var>action</var>, </code>...<code> } { <var>action</var>; </code>...<code>};</code></dt>
<dd>
decrement TTL; execute first set of actions if
successful, second set if TTL decrement fails
</dd>
- <dt><code>icmp_reply { <var>action</var>, </code>...<code> }</code></dt>
+ <dt><code>icmp_reply { <var>action</var>, </code>...<code> };</code></dt>
<dd>generate ICMP reply from packet, execute <var>action</var>s</dd>
<dt><code>arp { <var>action</var>, </code>...<code> }</code></dt>
<dd>generate ARP from packet, execute <var>action</var>s</dd>
</dl>
-
- <p>
- Other actions can be added as needed
- (e.g. <code>push_vlan</code>, <code>pop_vlan</code>,
- <code>push_mpls</code>, <code>pop_mpls</code>).
- </p>
-
- <p>
- Some of the OVN actions do not map directly to OpenFlow actions, e.g.:
- </p>
-
- <ul>
- <li>
- <code>with</code>: Implemented as <code>stack_push;
- set(</code>...<code>); <var>actions</var>; stack_pop</code>.
- </li>
-
- <li>
- <code>dec_ttl</code>: Implemented as <code>dec_ttl</code> followed
- by the successful actions. The failure case has to be implemented by
- ovn-controller interpreting packet-ins. It might be difficult to
- identify the particular place in the processing pipeline in
- <code>ovn-controller</code>; maybe some restrictions will be
- necessary.
- </li>
-
- <li>
- <code>icmp_reply</code>: Implemented by sending the packet to
- <code>ovn-controller</code>, which generates the ICMP reply and sends
- the packet back to <code>ovs-vswitchd</code>.
- </li>
- </ul>
</column>
</table>
--
1.7.10.4
More information about the dev
mailing list