With this patch applied:

I get 4 failures in kernel system tests and 8 failures in userspace system 
tests.




-----Original Message-----
From: <ovs-dev-boun...@openvswitch.org> on behalf of Justin Pettit 
<jpet...@ovn.org>
Date: Tuesday, August 8, 2017 at 4:12 PM
To: "d...@openvswitch.org" <d...@openvswitch.org>
Subject: [ovs-dev] [PATCH] ofproto-dpif: Mark packets as "untracked" after      
call to ct().

    Packet and Connection state is only available to the processing path
    that follows the "recirc_table" argument of the ct() action.  The
    previous behavior made these states available until the end of the
    pipeline.  This commit changes the behavior so that the Packet and
    Connection state are cleared for the current processing path whenever
    ct() is called (in addition to reaching the end of the pipeline.)
    
    A future commit will remove the behavior that a "send to controller"
    action causes all packets for that flow to be handled via the slow-path.
    The current behavior of connection tracking state makes that difficult
    due to datapath actions containing multiple OpenFlow rules that may
    contain different connection tracking states.  This change will make
    that future commit possible.
    
    Signed-off-by: Justin Pettit <jpet...@ovn.org>
    ---
     lib/ofp-actions.c            | 27 +++++++++++++--------------
     ofproto/ofproto-dpif-xlate.c | 24 +++++++-----------------
     tests/ofproto-dpif.at        | 10 +++++-----
     utilities/ovs-ofctl.8.in     | 10 ++++++----
     4 files changed, 31 insertions(+), 40 deletions(-)
    
    diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
    index bfc8a805ffd5..71eb70c3c239 100644
    --- a/lib/ofp-actions.c
    +++ b/lib/ofp-actions.c
    @@ -5858,20 +5858,19 @@ format_DEBUG_RECIRC(const struct ofpact_null *a 
OVS_UNUSED,
      *
      *   - Packet State:
      *
    - *      Untracked packets have not yet passed through the connection 
tracker,
    - *      and the connection state for such packets is unknown. In most 
cases,
    - *      packets entering the OpenFlow pipeline will initially be in the
    - *      untracked state. Untracked packets may become tracked by executing
    - *      NXAST_CT with a "recirc_table" specified. This makes various 
aspects
    - *      about the connection available, in particular the connection state.
    - *
    - *      Tracked packets have previously passed through the connection 
tracker.
    - *      These packets will remain tracked through until the end of the 
OpenFlow
    - *      pipeline. Tracked packets which have NXAST_CT executed with a
    - *      "recirc_table" specified will return to the tracked state.
    - *
    - *      The packet state is only significant for the duration of packet
    - *      processing within the OpenFlow pipeline.
    + *      Untracked packets have an unknown connection state.  In most
    + *      cases, packets entering the OpenFlow pipeline will initially be
    + *      in the untracked state. Untracked packets may become tracked by
    + *      executing NXAST_CT with a "recirc_table" specified. This makes
    + *      various aspects about the connection available, in particular
    + *      the connection state.
    + *
    + *      An NXAST_CT action always puts the packet into an untracked
    + *      state for the current processing path.  If "recirc_table" is
    + *      set, execution is forked and the packet passes through the
    + *      connection tracker.  The specified table's processing path is
    + *      able to match on Connection state until the end of the OpenFlow
    + *      pipeline or NXAST_CT is called again.
      *
      *   - Connection State:
      *
    diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
    index 973e760547fa..333b1b595e81 100644
    --- a/ofproto/ofproto-dpif-xlate.c
    +++ b/ofproto/ofproto-dpif-xlate.c
    @@ -5721,10 +5721,6 @@ put_ct_nat(struct xlate_ctx *ctx)
     static void
     compose_conntrack_action(struct xlate_ctx *ctx, struct ofpact_conntrack 
*ofc)
     {
    -    ovs_u128 old_ct_label = ctx->xin->flow.ct_label;
    -    ovs_u128 old_ct_label_mask = ctx->wc->masks.ct_label;
    -    uint32_t old_ct_mark = ctx->xin->flow.ct_mark;
    -    uint32_t old_ct_mark_mask = ctx->wc->masks.ct_mark;
         size_t ct_offset;
         uint16_t zone;
     
    @@ -5761,23 +5757,17 @@ compose_conntrack_action(struct xlate_ctx *ctx, 
struct ofpact_conntrack *ofc)
         ctx->ct_nat_action = NULL;
         nl_msg_end_nested(ctx->odp_actions, ct_offset);
     
    -    /* Restore the original ct fields in the key. These should only be 
exposed
    -     * after recirculation to another table. */
    -    ctx->xin->flow.ct_mark = old_ct_mark;
    -    ctx->wc->masks.ct_mark = old_ct_mark_mask;
    -    ctx->xin->flow.ct_label = old_ct_label;
    -    ctx->wc->masks.ct_label = old_ct_label_mask;
    -
    -    if (ofc->recirc_table == NX_CT_RECIRC_NONE) {
    -        /* If we do not recirculate as part of this action, hide the 
results of
    -         * connection tracking from subsequent recirculations. */
    -        ctx->conntracked = false;
    -    } else {
    +    if (ofc->recirc_table != NX_CT_RECIRC_NONE) {
             /* Use ct_* fields from datapath during recirculation upcall. */
             ctx->conntracked = true;
             compose_recirculate_and_fork(ctx, ofc->recirc_table);
    -        ctx->conntracked = false;
         }
    +
    +    /* The ct_* fields are only available in the scope of the
    +     * 'recirc_table' call chain. */
    +    flow_clear_conntrack(&ctx->xin->flow);
    +    flow_clear_conntrack(&ctx->wc->masks);
    +    ctx->conntracked = false;
     }
     
     static void
    diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
    index 284a65ec6524..28a7e827cac2 100644
    --- a/tests/ofproto-dpif.at
    +++ b/tests/ofproto-dpif.at
    @@ -8949,7 +8949,7 @@ OVS_WAIT_UNTIL([ovs-appctl -t ovs-ofctl exit])
     
     dnl Check this output. We only see the latter two packets, not the first.
     AT_CHECK([cat ofctl_monitor.log], [0], [dnl
    -NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
ct_state=new|trk,ct_zone=1,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=1,ct_tp_dst=2,reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x1,reg4=0x1,in_port=1
 (via action) data_len=42 (unbuffered)
    +NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x1,reg4=0x1,in_port=1 (via action) 
data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=1,tp_dst=2
 udp_csum:e9d6
     dnl
     NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
ct_state=est|rpl|trk,ct_zone=1,ct_mark=0x1,ct_label=0x4d2000000000000000000000000,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=1,ct_tp_dst=2,reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x2,reg4=0x1,in_port=2
 (via action) data_len=42 (unbuffered)
    @@ -8970,7 +8970,7 @@ OVS_WAIT_UNTIL([ovs-appctl -t ovs-ofctl exit])
     
     dnl Check this output. We should see both packets
     AT_CHECK([cat ofctl_monitor.log], [0], [dnl
    -NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
ct_state=new|trk,ct_zone=1,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=3,ct_tp_dst=2,reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x1,reg4=0x1,in_port=1
 (via action) data_len=42 (unbuffered)
    +NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x1,reg4=0x1,in_port=1 (via action) 
data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=3,tp_dst=2
 udp_csum:e9d4
     dnl
     NXT_PACKET_IN (xid=0x0): table_id=6 cookie=0x0 total_len=42 
ct_state=est|rpl|trk,ct_zone=1,ct_mark=0x1,ct_label=0x4d2000000000000000000000000,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=3,ct_tp_dst=2,reg0=0x1,reg1=0x4d2,reg2=0x1,reg3=0x2,reg4=0x1,in_port=2
 (via action) data_len=42 (unbuffered)
    @@ -9025,7 +9025,7 @@ AT_CHECK([cat ofctl_monitor.log], [0], [dnl
     NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=42 in_port=1 (via action) 
data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=1,tp_dst=2
 udp_csum:e9d6
     dnl
    -NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 
ct_state=est|rpl|trk,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=1,ct_tp_dst=2,in_port=2
 (via action) data_len=42 (unbuffered)
    +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 in_port=2 (via 
action) data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1
 udp_csum:e9d6
     ])
     
    @@ -9047,7 +9047,7 @@ AT_CHECK([cat ofctl_monitor.log], [0], [dnl
     NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=42 in_port=1 (via action) 
data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=3,tp_dst=4
 udp_csum:e9d2
     dnl
    -NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 
ct_state=est|rpl|trk,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=3,ct_tp_dst=4,in_port=2
 (via action) data_len=42 (unbuffered)
    +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 in_port=2 (via 
action) data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=4,tp_dst=3
 udp_csum:e9d2
     ])
     
    @@ -9362,7 +9362,7 @@ OVS_WAIT_UNTIL([ovs-appctl -t ovs-ofctl exit])
     
     dnl Check this output. We only see the latter two packets, not the first.
     AT_CHECK([cat ofctl_monitor.log], [0], [dnl
    -NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 
ct_state=new|trk,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=1,ct_tp_dst=2,in_port=1
 (via action) data_len=42 (unbuffered)
    +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 in_port=1 (via 
action) data_len=42 (unbuffered)
     
udp,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=1,tp_dst=2
 udp_csum:e9d6
     dnl
     NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x0 total_len=42 
ct_state=est|rpl|trk,ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=17,ct_tp_src=1,ct_tp_dst=2,in_port=2
 (via action) data_len=42 (unbuffered)
    diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
    index f6bd90374a18..c65de97f5e2e 100644
    --- a/utilities/ovs-ofctl.8.in
    +++ b/utilities/ovs-ofctl.8.in
    @@ -1031,11 +1031,13 @@ Restores the queue to the value it was before any 
\fBset_queue\fR
     actions were applied.
     .
     .IP \fBct\fR
    -.IQ \fBct\fB(\fR[\fIargument\fR][\fB,\fIargument\fR...]\fB)
    +.IQ \fBct(\fR[\fIargument\fR][\fB,\fIargument\fR...]\fB)
     Send the packet through the connection tracker.  Refer to the 
\fBct_state\fR
    -documentation above for possible packet and connection states. The 
following
    -arguments are supported:
    -
    +documentation above for possible packet and connection states. A \fBct\fR
    +action always sets the packet to an untracked state and clears out the
    +\fBct_state\fR fields for the current processing path.  Those fields are
    +only available for the processing path pointed to by the \fBtable\fR
    +argument.  The following arguments are supported:
     .RS
     .IP \fBcommit\fR
     .RS
    -- 
    2.7.4
    
    _______________________________________________
    dev mailing list
    d...@openvswitch.org
    
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=0zUUtGTqA0rQPJshxslL-2FLBopCJJ8Fp6o61txtq4U&s=jTQyR94DiGGkyGn7myT8AHsq2kgY_XWC-w4nvIDGdTk&e=
 
    

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to