Re: [ovs-dev] [PATCH] ovs-advanced.rst: Add missing \ to a few examples.

[Ben Pfaff]

On Fri, Dec 23, 2016 at 05:27:05PM -0800, Mickey Spiegel wrote:
> On Tue, Dec 20, 2016 at 5:06 PM, Ben Pfaff  wrote:
> 
> > This makes these examples easier to cut and paste into a terminal, and
> > makes them consistent with the other examples.
> >
> > Signed-off-by: Ben Pfaff 
> >
> 
> Acked-by: Mickey Spiegel 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] how a trunk port treats untagged packets

[Ben Pfaff]

On Sat, Dec 24, 2016 at 11:50:00AM +0800, 贺斌 wrote:
> hello all,
>I'm a ovs beginer. Recently, I test on ovs trunk port:
>1. I created a ovs bridge named br0, and then add two trunk ports on it,  
> named if0, if1. And the trunk is the same, 44,55,66.
>2. Then I put intreface if0 to Linux name space ns0, and if1 to ns1.
>3. Associate a ip 110.0.0.2/24 on if0 in ns0 and 110.0.0.2/24 on if1 in 
> ns1.
>4. The I execute 'ping 110.0.0.3' from ns0, But I can't get any packet 
> captured on default intterface br0 or if1 in ns1 using 'tcpdump'. But when I 
> use comman 'ovs-ofctl dump-flows br0',  I find that every time after I excute 
> ping commands, there is an increase of 3 for 'n_packets' in the flow. I guest 
> it's arp packets. But I can't capture it from any where.
> 
> 
>  I'm sure all the interface is up,  and  the route table is corret.
>  
>  So, I wonder that, when an untagged packet passed to the trunk port 
> directly, how the ovs brigde treat it? Drop it directly or add a default VLAN 
> id then forwarding it?

Untagged packets are in VLAN 0.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] how a trunk port treats untagged packets

[贺斌]

hello all,
   I'm a ovs beginer. Recently, I test on ovs trunk port:
   1. I created a ovs bridge named br0, and then add two trunk ports on it,  
named if0, if1. And the trunk is the same, 44,55,66.
   2. Then I put intreface if0 to Linux name space ns0, and if1 to ns1.
   3. Associate a ip 110.0.0.2/24 on if0 in ns0 and 110.0.0.2/24 on if1 in ns1.
   4. The I execute 'ping 110.0.0.3' from ns0, But I can't get any packet 
captured on default intterface br0 or if1 in ns1 using 'tcpdump'. But when I 
use comman 'ovs-ofctl dump-flows br0',  I find that every time after I excute 
ping commands, there is an increase of 3 for 'n_packets' in the flow. I guest 
it's arp packets. But I can't capture it from any where.


 I'm sure all the interface is up,  and  the route table is corret.
 
 So, I wonder that, when an untagged packet passed to the trunk port directly, 
how the ovs brigde treat it? Drop it directly or add a default VLAN id then 
forwarding it?


 Best wishes.
 
 hebin.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 2/3] conntrack: Return NEW for IPv6 ND packets without tracking.

[Daniele Di Proietto]

On 22/12/2016 21:20, "Darrell Ball"  wrote:

>Some comments inline

Thanks for the review, I've sent a v3

>
>On 12/22/16, 6:36 PM, "Daniele Di Proietto"  wrote:
>
>The userspace connection tracker treats Neighbor Discovery packets
>as invalid, because they're not checked against any connection.
>
>This in inconsistent with the kernel connection tracker which always
>returns 'CS_NEW'.
>
>Therefore, this commit makes the userspace connection tracker conforming
>with the kernel.  ND packets still do not create or read any state, but
>they're treated as NEW.
>
>To support this, the key extraction functions can now return
>KEY_NO_TRACK, meaning that the packet is ok, but it should be treated
>statelessly.
>
>
>s/To support this, the key extraction functions can now return
>KEY_NO_TRACK, meaning that the packet is ok, but it should be treated
>statelessly.
>/
>To support this, the key extraction functions can now return
>KEY_NO_TRACK, meaning the packet should be treated statelessly
>and not be sent to the connection tracker.
>/

ok, changed

>
>
>We also have to remove a test that explicitly checked that neighbor
>discovery was treated as invalid.
>
>Reported-by: Sridhar Gaddam 
>Signed-off-by: Daniele Di Proietto 
>---
>v2: Update comment to reflect that we do not do special validation with
>the packet.
>---
> lib/conntrack.c | 134 
> 
> tests/ofproto-dpif.at   |  32 
> tests/system-traffic.at |  35 +
> 3 files changed, 125 insertions(+), 76 deletions(-)
>
>diff --git a/lib/conntrack.c b/lib/conntrack.c
>index 9bea3d9..86228d6 100644
>--- a/lib/conntrack.c
>+++ b/lib/conntrack.c
>@@ -52,9 +52,17 @@ struct conn_lookup_ctx {
> bool related;
> };
> 
>-static bool conn_key_extract(struct conntrack *, struct dp_packet *,
>- ovs_be16 dl_type, struct conn_lookup_ctx *,
>- uint16_t zone);
>+enum key_status {
>+KEY_INVALID,   /* Could not extract the connection key: invalid. */
>+KEY_OK,/* Connection key is ok. */
>+KEY_NO_TRACK,  /* Connection key is ok, but it should not be tracked. 
> */
>
>
>KEY_NO_TRACK,  /* Connection key should not be tracked. */

ok

>
>
>+};
>+
>+static enum key_status conn_key_extract(struct conntrack *,
>+struct dp_packet *,
>+ovs_be16 dl_type,
>+struct conn_lookup_ctx *,
>+uint16_t zone);
> static uint32_t conn_key_hash(const struct conn_key *, uint32_t basis);
> static void conn_key_reverse(struct conn_key *);
> static void conn_key_lookup(struct conntrack_bucket *ctb,
>@@ -157,6 +165,20 @@ static unsigned hash_to_bucket(uint32_t hash)
> return (hash >> (32 - CONNTRACK_BUCKETS_SHIFT)) % CONNTRACK_BUCKETS;
> }
> 
>+static uint16_t
>+key_status_to_cs(enum key_status s)
>+{
>+switch (s) {
>+case KEY_INVALID:
>+return CS_INVALID;
>+case KEY_OK:
>+case KEY_NO_TRACK:
>+return CS_NEW;
>+default:
>+OVS_NOT_REACHED();
>+}
>+}
>+
> static void
> write_ct_md(struct dp_packet *pkt, uint16_t state, uint16_t zone,
> uint32_t mark, ovs_u128 label)
>@@ -303,10 +325,13 @@ conntrack_execute(struct conntrack *ct, struct 
> dp_packet_batch *pkt_batch,
> 
> memset(bucket_list, INT8_C(-1), sizeof bucket_list);
> for (i = 0; i < cnt; i++) {
>+enum key_status extract_res;
> unsigned bucket;
> 
>-if (!conn_key_extract(ct, pkts[i], dl_type, [i], zone)) {
>-write_ct_md(pkts[i], CS_INVALID, zone, 0, OVS_U128_ZERO);
>+extract_res = conn_key_extract(ct, pkts[i], dl_type, [i], 
> zone);
>+if (extract_res != KEY_OK) {
>+write_ct_md(pkts[i], key_status_to_cs(extract_res), zone, 0,
>+OVS_U128_ZERO);
> continue;
> }
> 
>@@ -693,8 +718,11 @@ extract_l4_udp(struct conn_key *key, const void 
> *data, size_t size)
> return key->src.port && key->dst.port;
> }
> 
>-static inline bool extract_l4(struct conn_key *key, const void *data,
>-  size_t size, bool *related, const void *l3);
>+static inline enum key_status extract_l4(struct conn_key *key,
>+ const void *data,
>+ size_t size,
>+

Re: [ovs-dev] [PATCH v2 1/3] conntrack: Do not create new connections from ICMP errors.

[Daniele Di Proietto]

On 22/12/2016 18:55, "Darrell Ball"  wrote:

>
>
>On 12/22/16, 6:36 PM, "Daniele Di Proietto"  wrote:
>
>ICMP error packets (e.g. destination unreachable messages) are
>considered 'related' to another connection and are treated as part of
>that.
>
>However:
>
>* We shouldn't create new entries in the connection table if the
>  original connection is not found.  This is consistent with what the
>  kernel does.
>* We certainly shouldn't call valid_new() on the packet, because
>  valid_new() assumes the packet l4 type (might be TCP, UDP or ICMP)
>  to be consistent with the conn_key nw_proto type.
>
>Found by inspection.
>
>Fixes: a489b16854b5("conntrack: New userspace connection tracker.")
>Signed-off-by: Daniele Di Proietto 
>---
>v2: Handle ICMP error for non existing connection in else branch without
>restructuring the whole code flow.
>---
> lib/conntrack.c |  6 +-
> tests/system-traffic.at | 27 ---
> 2 files changed, 21 insertions(+), 12 deletions(-)
>
>
>Acked-by: Darrell Ball 

Thanks, I pushed this to master and branch-2.6

>
>diff --git a/lib/conntrack.c b/lib/conntrack.c
>index 7c50a28..9bea3d9 100644
>--- a/lib/conntrack.c
>+++ b/lib/conntrack.c
>@@ -247,7 +247,11 @@ process_one(struct conntrack *ct, struct dp_packet 
> *pkt,
> }
> }
> } else {
>-conn = conn_not_found(ct, pkt, ctx, , commit, now);
>+if (ctx->related) {
>+state |= CS_INVALID;
>+} else {
>+conn = conn_not_found(ct, pkt, ctx, , commit, now);
>+}
> }
> 
> write_ct_md(pkt, state, zone, conn ? conn->mark : 0,
>diff --git a/tests/system-traffic.at b/tests/system-traffic.at
>index 9ea6d6b..a5023d3 100644
>--- a/tests/system-traffic.at
>+++ b/tests/system-traffic.at
>@@ -1331,12 +1331,8 @@ ADD_VETH(p1, at_ns1, br0, "172.16.0.2/24")
> 
> dnl Allow any traffic from ns0->ns1. Only allow nd, return traffic from 
> ns1->ns0.
> AT_DATA([flows.txt], [dnl
>-priority=1,action=drop
>-priority=10,arp,action=normal
>-priority=100,in_port=1,udp,ct_state=-trk,action=ct(commit,table=0)
>-priority=100,in_port=1,ip,ct_state=+trk,actions=controller
>-priority=100,in_port=2,ip,ct_state=-trk,action=ct(table=0)
>-priority=100,in_port=2,ip,ct_state=+trk+rel+rpl,action=controller
>+table=0,ip,action=ct(commit,table=1)
>+table=1,ip,action=controller
> ])
> 
> AT_CHECK([ovs-ofctl --bundle replace-flows br0 flows.txt])
>@@ -1345,22 +1341,31 @@ AT_CAPTURE_FILE([ofctl_monitor.log])
> AT_CHECK([ovs-ofctl monitor br0 65534 invalid_ttl --detach --no-chdir 
> --pidfile 2> ofctl_monitor.log])
> 
> dnl 1. Send an ICMP port unreach reply for port 8738, without any 
> previous request
>-AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 2 ct\(table=0\) 
> 'f64c473528c9c6f54ecb72db080045c0003d2e874001f355ac14ac130303553f4521317040004011b138ac13ac14000d20966369616f0a'])
>+AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 2 resubmit\(,0\) 
> 'f64c473528c9c6f54ecb72db080045c0003d2e874001f351ac14ac130303da494521317040004011b138ac13ac14000d20966369616f0a'])
> 
> dnl 2. Send and UDP packet to port 
>-AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 1 ct\(commit,table=0\) 
> 'c6f94ecb72dbe64c473528c908004521317040004011b138ac11ac12a28e15b3000d20966369616f0a'])
>+AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 1 resubmit\(,0\) 
> 'c6f94ecb72dbe64c473528c908004521317040004011b138ac11ac12a28e15b3000d20966369616f0a'])
> 
> dnl 3. Send an ICMP port unreach reply for port , related to the 
> first packet
>-AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 2 ct\(table=0\) 
> 'e64c473528c9c6f94ecb72db080045c0003d2e874001f355ac12ac110303553f4521317040004011b138ac11ac12a28e15b3000d20966369616f0a'])
>+AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 2 resubmit\(,0\) 
> 'e64c473528c9c6f94ecb72db080045c0003d2e874001f355ac12ac110303553f4521317040004011b138ac11ac12a28e15b3000d20966369616f0a'])
> 
> dnl Check this output. We only see the latter two packets, not the first.
> AT_CHECK([cat ofctl_monitor.log], [0], [dnl
>-NXT_PACKET_IN2 (xid=0x0): cookie=0x0 total_len=47 
> ct_state=new|trk,in_port=1 (via action) data_len=47 (unbuffered)
>+NXT_PACKET_IN2 (xid=0x0): table_id=1 cookie=0x0 total_len=75 
> ct_state=inv|trk,in_port=2 (via action) data_len=75 (unbuffered)
>
> 

[ovs-dev] [PATCH v3 1/2] conntrack: Return NEW for IPv6 ND packets without tracking.

[Daniele Di Proietto]

The userspace connection tracker treats Neighbor Discovery packets
as invalid, because they're not checked against any connection.

This in inconsistent with the kernel connection tracker which always
returns 'CS_NEW'.

Therefore, this commit makes the userspace connection tracker conforming
with the kernel.  ND packets still do not create or read any state, but
they're treated as NEW.

To support this, the key extraction functions can now return
KEY_NO_TRACK, meaning the packet should be treated statelessly and not
be sent to the connection tracker.

We also have to remove a test that explicitly checked that neighbor
discovery was treated as invalid.

Reported-by: Sridhar Gaddam 
Signed-off-by: Daniele Di Proietto 
---
 lib/conntrack.c | 134 
 tests/ofproto-dpif.at   |  32 
 tests/system-traffic.at |  95 ++
 3 files changed, 185 insertions(+), 76 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 9bea3d9..d2b5f3a 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -52,9 +52,17 @@ struct conn_lookup_ctx {
 bool related;
 };
 
-static bool conn_key_extract(struct conntrack *, struct dp_packet *,
- ovs_be16 dl_type, struct conn_lookup_ctx *,
- uint16_t zone);
+enum key_status {
+KEY_INVALID,   /* Could not extract the connection key: invalid. */
+KEY_OK,/* Connection key is ok. */
+KEY_NO_TRACK,  /* Connection key should not be tracked. */
+};
+
+static enum key_status conn_key_extract(struct conntrack *,
+struct dp_packet *,
+ovs_be16 dl_type,
+struct conn_lookup_ctx *,
+uint16_t zone);
 static uint32_t conn_key_hash(const struct conn_key *, uint32_t basis);
 static void conn_key_reverse(struct conn_key *);
 static void conn_key_lookup(struct conntrack_bucket *ctb,
@@ -157,6 +165,20 @@ static unsigned hash_to_bucket(uint32_t hash)
 return (hash >> (32 - CONNTRACK_BUCKETS_SHIFT)) % CONNTRACK_BUCKETS;
 }
 
+static uint16_t
+key_status_to_cs(enum key_status s)
+{
+switch (s) {
+case KEY_INVALID:
+return CS_INVALID;
+case KEY_OK:
+case KEY_NO_TRACK:
+return CS_NEW;
+default:
+OVS_NOT_REACHED();
+}
+}
+
 static void
 write_ct_md(struct dp_packet *pkt, uint16_t state, uint16_t zone,
 uint32_t mark, ovs_u128 label)
@@ -303,10 +325,13 @@ conntrack_execute(struct conntrack *ct, struct 
dp_packet_batch *pkt_batch,
 
 memset(bucket_list, INT8_C(-1), sizeof bucket_list);
 for (i = 0; i < cnt; i++) {
+enum key_status extract_res;
 unsigned bucket;
 
-if (!conn_key_extract(ct, pkts[i], dl_type, [i], zone)) {
-write_ct_md(pkts[i], CS_INVALID, zone, 0, OVS_U128_ZERO);
+extract_res = conn_key_extract(ct, pkts[i], dl_type, [i], zone);
+if (extract_res != KEY_OK) {
+write_ct_md(pkts[i], key_status_to_cs(extract_res), zone, 0,
+OVS_U128_ZERO);
 continue;
 }
 
@@ -693,8 +718,11 @@ extract_l4_udp(struct conn_key *key, const void *data, 
size_t size)
 return key->src.port && key->dst.port;
 }
 
-static inline bool extract_l4(struct conn_key *key, const void *data,
-  size_t size, bool *related, const void *l3);
+static inline enum key_status extract_l4(struct conn_key *key,
+ const void *data,
+ size_t size,
+ bool *related,
+ const void *l3);
 
 static uint8_t
 reverse_icmp_type(uint8_t type)
@@ -724,14 +752,14 @@ reverse_icmp_type(uint8_t type)
  * instead and set *related to true.  If 'related' is NULL we're
  * already processing a nested header and no such recursion is
  * possible */
-static inline int
+static inline enum key_status
 extract_l4_icmp(struct conn_key *key, const void *data, size_t size,
 bool *related)
 {
 const struct icmp_header *icmp = data;
 
 if (OVS_UNLIKELY(size < ICMP_HEADER_LEN)) {
-return false;
+return KEY_INVALID;
 }
 
 switch (icmp->icmp_type) {
@@ -742,13 +770,15 @@ extract_l4_icmp(struct conn_key *key, const void *data, 
size_t size,
 case ICMP4_INFOREQUEST:
 case ICMP4_INFOREPLY:
 if (icmp->icmp_code != 0) {
-return false;
+return KEY_INVALID;
 }
 /* Separate ICMP connection: identified using id */
 key->src.icmp_id = key->dst.icmp_id = icmp->icmp_fields.echo.id;
 key->src.icmp_type = icmp->icmp_type;
 key->dst.icmp_type = reverse_icmp_type(icmp->icmp_type);
-break;
+
+return KEY_OK;
+
 

[ovs-dev] [PATCH v3 2/2] conntrack: Use 'maybe_related' insted of 'related'.

[Daniele Di Proietto]

This is just a naming change.  When we extract the key of an ICMP error
message we suspect that it might be related, but we're not sure until we
perform a lookup in the connection table.

Suggested-by: Darrell Ball 
Signed-off-by: Daniele Di Proietto 
Acked-by: Darrell Ball 
---
 lib/conntrack.c | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index d2b5f3a..a9627f9 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -49,7 +49,7 @@ struct conn_lookup_ctx {
 struct conn *conn;
 uint32_t hash;
 bool reply;
-bool related;
+bool maybe_related;
 };
 
 enum key_status {
@@ -236,7 +236,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
 uint16_t state = 0;
 
 if (conn) {
-if (ctx->related) {
+if (ctx->maybe_related) {
 state |= CS_RELATED;
 if (ctx->reply) {
 state |= CS_REPLY_DIR;
@@ -269,7 +269,7 @@ process_one(struct conntrack *ct, struct dp_packet *pkt,
 }
 }
 } else {
-if (ctx->related) {
+if (ctx->maybe_related) {
 state |= CS_INVALID;
 } else {
 conn = conn_not_found(ct, pkt, ctx, , commit, now);
@@ -721,7 +721,7 @@ extract_l4_udp(struct conn_key *key, const void *data, 
size_t size)
 static inline enum key_status extract_l4(struct conn_key *key,
  const void *data,
  size_t size,
- bool *related,
+ bool *maybe_related,
  const void *l3);
 
 static uint8_t
@@ -747,14 +747,14 @@ reverse_icmp_type(uint8_t type)
 }
 }
 
-/* If 'related' is not NULL and the function is processing an ICMP
+/* If 'maybe_related' is not NULL and the function is processing an ICMP
  * error packet, extract the l3 and l4 fields from the nested header
- * instead and set *related to true.  If 'related' is NULL we're
+ * instead and set *maybe_related to true.  If 'maybe_related' is NULL we're
  * already processing a nested header and no such recursion is
  * possible */
 static inline enum key_status
 extract_l4_icmp(struct conn_key *key, const void *data, size_t size,
-bool *related)
+bool *maybe_related)
 {
 const struct icmp_header *icmp = data;
 
@@ -793,7 +793,7 @@ extract_l4_icmp(struct conn_key *key, const void *data, 
size_t size,
 enum key_status res;
 bool ok;
 
-if (!related) {
+if (!maybe_related) {
 return KEY_INVALID;
 }
 
@@ -817,7 +817,7 @@ extract_l4_icmp(struct conn_key *key, const void *data, 
size_t size,
 res = extract_l4(key, l4, tail - l4, NULL, l3);
 if (res != KEY_INVALID) {
 conn_key_reverse(key);
-*related = true;
+*maybe_related = true;
 }
 return res;
 }
@@ -839,14 +839,14 @@ reverse_icmp6_type(uint8_t type)
 }
 }
 
-/* If 'related' is not NULL and the function is processing an ICMP
+/* If 'maybe_related' is not NULL and the function is processing an ICMP
  * error packet, extract the l3 and l4 fields from the nested header
- * instead and set *related to true.  If 'related' is NULL we're
+ * instead and set *maybe_related to true.  If 'maybe_related' is NULL we're
  * already processing a nested header and no such recursion is
  * possible */
 static inline enum key_status
 extract_l4_icmp6(struct conn_key *key, const void *data, size_t size,
- bool *related)
+ bool *maybe_related)
 {
 const struct icmp6_header *icmp6 = data;
 
@@ -882,7 +882,7 @@ extract_l4_icmp6(struct conn_key *key, const void *data, 
size_t size,
 enum key_status res;
 bool ok;
 
-if (!related) {
+if (!maybe_related) {
 return KEY_INVALID;
 }
 
@@ -908,7 +908,7 @@ extract_l4_icmp6(struct conn_key *key, const void *data, 
size_t size,
 res = extract_l4(key, l4, tail - l4, NULL, l3);
 if (res != KEY_INVALID) {
 conn_key_reverse(key);
-*related = true;
+*maybe_related = true;
 }
 return res;
 }
@@ -929,33 +929,33 @@ extract_l4_icmp6(struct conn_key *key, const void *data, 
size_t size,
 /* Extract l4 fields into 'key', which must already contain valid l3
  * members.
  *
- * If 'related' is not NULL and an ICMP error packet is being
+ * If 'maybe_related' is not NULL and an ICMP error packet is being
  * processed, the function will extract the key from the packet nested
- * in the ICMP paylod and set '*related' to true.
+ * in the ICMP paylod and set '*maybe_related' to true.
  *
- * If 'related' is NULL, it means that we're already parsing a header nested
+ * If 'maybe_related' is 

Re: [ovs-dev] [PATCH] ovs-advanced.rst: Add missing \ to a few examples.

[Mickey Spiegel]

On Tue, Dec 20, 2016 at 5:06 PM, Ben Pfaff  wrote:

> This makes these examples easier to cut and paste into a terminal, and
> makes them consistent with the other examples.
>
> Signed-off-by: Ben Pfaff 
>

Acked-by: Mickey Spiegel 


> ---
>  Documentation/tutorials/ovs-advanced.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/tutorials/ovs-advanced.rst
> b/Documentation/tutorials/ovs-advanced.rst
> index 4ae27ce..d14b2f9 100644
> --- a/Documentation/tutorials/ovs-advanced.rst
> +++ b/Documentation/tutorials/ovs-advanced.rst
> @@ -809,11 +809,11 @@ because the VLAN only belongs to the input port::
>
>  Try some other broadcast cases on your own::
>
> -$ ovs-appctl ofproto/trace br0
> +$ ovs-appctl ofproto/trace br0 \
>  in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=20
> -$ ovs-appctl ofproto/trace br0
> +$ ovs-appctl ofproto/trace br0 \
>  in_port=2,dl_dst=ff:ff:ff:ff:ff:ff
> -$ ovs-appctl ofproto/trace br0
> +$ ovs-appctl ofproto/trace br0 \
>  in_port=4,dl_dst=ff:ff:ff:ff:ff:ff
>
>  You can see the same behavior with multicast packets and with unicast
> --
> 2.10.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Bug#840770: marked as done (openvswitch: FTBFS on almost all big-endian architectures: 954: ofproto-dpif - in place modification (vlan) FAILED (ofproto-dpif.at:7237))

[Debian Bug Tracking System]

Your message dated Sat, 24 Dec 2016 01:04:10 +
with message-id 
and subject line Bug#840770: fixed in openvswitch 2.6.2~pre+git20161223-2
has caused the Debian Bug report #840770,
regarding openvswitch: FTBFS on almost all big-endian architectures: 954: 
ofproto-dpif - in place modification (vlan) FAILED (ofproto-dpif.at:7237)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
840770: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840770
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] openvswitch_2.6.2~pre+git20161223-2_i386.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 23 Dec 2016 16:35:11 -0800
Source: openvswitch
Binary: openvswitch-common openvswitch-switch ovn-common ovn-controller-vtep 
ovn-host ovn-central ovn-docker openvswitch-ipsec openvswitch-pki 
openvswitch-testcontroller openvswitch-dbg python-openvswitch openvswitch-test 
openvswitch-vtep openvswitch-dev
Architecture: source i386 all
Version: 2.6.2~pre+git20161223-2
Distribution: unstable
Urgency: medium
Maintainer: Open vSwitch developers 
Changed-By: Ben Pfaff 
Description:
 openvswitch-common - Open vSwitch common components
 openvswitch-dbg - Debug symbols for Open vSwitch packages
 openvswitch-dev - Open vSwitch development package
 openvswitch-ipsec - Open vSwitch GRE-over-IPsec support
 openvswitch-pki - Open vSwitch public key infrastructure dependency package
 openvswitch-switch - Open vSwitch switch implementations
 openvswitch-test - Open vSwitch test package
 openvswitch-testcontroller - Simple controller for testing OpenFlow setups
 openvswitch-vtep - Open vSwitch VTEP utilities
 ovn-central - OVN central components
 ovn-common - OVN common components
 ovn-controller-vtep - OVN vtep controller
 ovn-docker - OVN Docker drivers
 ovn-host   - OVN host components
 python-openvswitch - Python bindings for Open vSwitch
Closes: 828478 840770
Changes:
 openvswitch (2.6.2~pre+git20161223-2) unstable; urgency=medium
 .
   * Apply upstream patches:
 - c8ad60e debian: Also restrict ovn-docker package to Linux.
 - 90c25ef tests: Fix race in "ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS".
 - 6fe9954 rconn: Avoid abort for ill-behaved remote.
   * Builds fine with OpenSSL 1.1.  Closes: #828478.
   * Upstream bug fixes from this and previous upload fix endianness issues.
 Closes: #840770.
Checksums-Sha1:
 95cb3129c796317c0a70d9175433fc0cf4ad8eab 3019 
openvswitch_2.6.2~pre+git20161223-2.dsc
 3bba3f116298d0bd0c52d2de68361e0cea501216 51820 
openvswitch_2.6.2~pre+git20161223-2.debian.tar.xz
 72fb9804024c21864fcf2fe7e38fff1f79ee5ae6 1314010 
openvswitch-common_2.6.2~pre+git20161223-2_i386.deb
 638cf11d6aca7fc37ad308aff9eee57f16cb3120 3000904 
openvswitch-dbg_2.6.2~pre+git20161223-2_i386.deb
 b8c4bc8705c55812e7b59339cc99e23530db5070 1552124 
openvswitch-dev_2.6.2~pre+git20161223-2_i386.deb
 c47e5765a3669cbb511cffd49f9ad6a9cb3ed5c8 43432 
openvswitch-ipsec_2.6.2~pre+git20161223-2_i386.deb
 774488f3e0869e4e98a603d5a3d975bc46b2ea09 36788 
openvswitch-pki_2.6.2~pre+git20161223-2_all.deb
 856abdb4592bccb708b26c3f84389408644eb582 270270 
openvswitch-switch_2.6.2~pre+git20161223-2_i386.deb
 9500146a1a47b47841c5f46f5f188ee6d41b074b 52640 
openvswitch-test_2.6.2~pre+git20161223-2_all.deb
 7402194dd65bb23af57dca3604b2e13e5f668b67 52568 
openvswitch-testcontroller_2.6.2~pre+git20161223-2_i386.deb
 eaa4f34eb7a506312777483b9bb793fef0742526 59418 
openvswitch-vtep_2.6.2~pre+git20161223-2_i386.deb
 04285356dcbbdaa7bbdb57a776ae3669b319e3ec 11730 
openvswitch_2.6.2~pre+git20161223-2_i386.buildinfo
 0d5639c9756ddae611fe2c9a5190ac2c42c90efe 82682 
ovn-central_2.6.2~pre+git20161223-2_i386.deb
 f1a78df76352689fc27b445a46cfbca014e0323e 151910 
ovn-common_2.6.2~pre+git20161223-2_i386.deb
 33d62a5f81f34a8de966d4b448348fc5c4592ceb 49730 
ovn-controller-vtep_2.6.2~pre+git20161223-2_i386.deb
 3e02abed332de9045256bf4a5f73ad163bec3057 40658 
ovn-docker_2.6.2~pre+git20161223-2_i386.deb
 2a5878559aa9f205c80ada5102d5e75be81ddf62 81888 
ovn-host_2.6.2~pre+git20161223-2_i386.deb
 cc662b39bd8230646a54716d1ea6111acc054a2e 91420 
python-openvswitch_2.6.2~pre+git20161223-2_all.deb
Checksums-Sha256:
 b8ebbb90ba278f6c079053e1e43edbaccbf805e18a4bbe9111cd571401005fb0 3019 
openvswitch_2.6.2~pre+git20161223-2.dsc
 804fe99281d3cb12610c158891efe733064c43a7bb385f5b82c51f8c23681bd8 51820 
openvswitch_2.6.2~pre+git20161223-2.debian.tar.xz
 f92f77ac4a349886b13fad90f3bda5cf16d26deed23be9d9b8562ec0d54c8934 1314010 
openvswitch-common_2.6.2~pre+git20161223-2_i386.deb
 1bdaaf9ad1953a57035153cc6ae894f0ef79c25f2a54562bdb9c5593688da906 3000904 
openvswitch-dbg_2.6.2~pre+git20161223-2_i386.deb
 87267ccc5629fa03af59e93fd3379ca7f852eb8f4bb886d6e6f8f68c506c8132 1552124 
openvswitch-dev_2.6.2~pre+git20161223-2_i386.deb
 eb2f01b9ee43a1e63de67543102af3cbc766c266621815616de0ac6d6022d7d3 43432 
openvswitch-ipsec_2.6.2~pre+git20161223-2_i386.deb
 3144e1cee5f29ac8661799d856f6eed2d6abd9a7a8cd8d3afc0fb261ca1bde52 36788 
openvswitch-pki_2.6.2~pre+git20161223-2_all.deb
 1e7f8c81ad49c0260900eaa1da3fec929bfea1788fc0b4345611fed04b88c84e 270270 
openvswitch-switch_2.6.2~pre+git20161223-2_i386.deb
 927e36716fcca4b2e420f76499f0c123f8870039fb3e33e55a9fa75f58f57b0c 52640 
openvswitch-test_2.6.2~pre+git20161223-2_all.deb
 8aad057ac43e585b66e7e68a7925825ae8b6f8b6516fbf1584fbf74b1199e5ce 52568 
openvswitch-testcontroller_2.6.2~pre+git20161223-2_i386.deb
 364551054f36979ecee30fc2c0b5fb774a6df685511c5f78a3358d6fa364a11a 59418 

[ovs-dev] Processing of openvswitch_2.6.2~pre+git20161223-2_i386.changes

[Debian FTP Masters]

openvswitch_2.6.2~pre+git20161223-2_i386.changes uploaded successfully to 
localhost
along with the files:
  openvswitch_2.6.2~pre+git20161223-2.dsc
  openvswitch_2.6.2~pre+git20161223-2.debian.tar.xz
  openvswitch-common_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-dbg_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-dev_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-ipsec_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-pki_2.6.2~pre+git20161223-2_all.deb
  openvswitch-switch_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-test_2.6.2~pre+git20161223-2_all.deb
  openvswitch-testcontroller_2.6.2~pre+git20161223-2_i386.deb
  openvswitch-vtep_2.6.2~pre+git20161223-2_i386.deb
  openvswitch_2.6.2~pre+git20161223-2_i386.buildinfo
  ovn-central_2.6.2~pre+git20161223-2_i386.deb
  ovn-common_2.6.2~pre+git20161223-2_i386.deb
  ovn-controller-vtep_2.6.2~pre+git20161223-2_i386.deb
  ovn-docker_2.6.2~pre+git20161223-2_i386.deb
  ovn-host_2.6.2~pre+git20161223-2_i386.deb
  python-openvswitch_2.6.2~pre+git20161223-2_all.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovs-advanced.rst: Add missing \ to a few examples.

[Ben Pfaff]

On Tue, Dec 20, 2016 at 05:06:49PM -0800, Ben Pfaff wrote:
> This makes these examples easier to cut and paste into a terminal, and
> makes them consistent with the other examples.
> 
> Signed-off-by: Ben Pfaff 

I'd appreciate it if someone would review this trivial patch.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] make: Add 'doc-check' target

[Ben Pfaff]

On Fri, Dec 23, 2016 at 11:04:12PM +, Stephen Finucane wrote:
> This does basic validation of the syntax and validates all external
> links.
> 
> The nitpick ('-n') flag is added to ensure all possible warnings are
> raised.
> 
> Signed-off-by: Stephen Finucane 
> Cc: Ben Pfaff 

This does seem pretty fantastic, but it's really slow and requires
network access.  It'd be nice for running occasionally (or to add to the
travis build), but I don't think we should run it on every build.  Also,
it complain
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366510(v=vs.85).aspx

I was envisioning something that just checked internal links.  I think
that, if I change linkcheck to html, this comes pretty close to that.
On my machine, that takes 4.2 seconds from a clean build, which is slow
for running on every build, but it takes less than .3 seconds the second
time with no changes, which I think would be acceptable.

Also, I think that we can probably make reruns even faster than .3
seconds if we make docs-check a real target by making it depend on the
files that generate the documentation, so that docs only get rebuilt if
any of their sources changed.  Something like this:

ALL_LOCAL += docs-check
docs-check: $(EXTRA_DIST)
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) -q $(SPHINXBUILDDIR)/html
touch $@

and, you know, at that point really we don't have a check anymore, we
have actual HTML docs that always get nicely generated whenever we run
"make", which is pretty nice, so that we might as well just:

ALL_LOCAL += htmldocs
htmldocs: $(EXTRA_DIST)
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/html
touch $@

Right?  Well, except that $(EXTRA_DIST) is obviously not the right
dependency, presumably there should be a better variable.

(And of course we'd want to wrap the whole thing in "if HAVE_SPHINX",
once we have that.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] packets: Simplify packet_csum_pseudoheader6().

[Ben Pfaff]

On Fri, Dec 23, 2016 at 01:46:53PM -0800, Andy Zhou wrote:
> On Fri, Dec 23, 2016 at 9:06 AM, Ben Pfaff  wrote:
> 
> > It's simpler to make two calls than eight.
> >
> > Reported-by: Eelco Chaudron 
> > Signed-off-by: Ben Pfaff 
> 
> 
> Acked-by: Andy Zhou 

Thank you.  I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] debian: Also restrict ovn-docker package to Linux.

[Ben Pfaff]

On Fri, Dec 23, 2016 at 02:18:38PM -0800, Justin Pettit wrote:
> 
> > On Dec 23, 2016, at 1:45 PM, Ben Pfaff  wrote:
> > 
> > The Debian packages for OVS have only supported Linux so far, but the
> > ovn-docker package was mistakenly marked as Architecture: any instead
> > of linux-any, which caused build failures.  This fixes the problem.
> > 
> > (Perhaps OVS packaging for Debian should also support BSD, but that
> > would be a bigger change.)
> > 
> > Reported-at: 
> > https://buildd.debian.org/status/fetch.php?pkg=openvswitch=kfreebsd-amd64=2.6.2%7Epre%2Bgit20161223-1=1482518318=log
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Justin Pettit 

Thank you.  I applied this to master and branch-2.6.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] tests: Fix race in "ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS".

[Ben Pfaff]

On Fri, Dec 23, 2016 at 02:18:00PM -0800, Justin Pettit wrote:
> 
> > On Dec 23, 2016, at 1:34 PM, Ben Pfaff  wrote:
> > 
> > The 1-second sleep to wait for the bind to occur is not long enough on
> > slow mips machines.  This fixes the problem.
> > 
> > Reported-at: 
> > https://buildd.debian.org/status/fetch.php?pkg=openvswitch=mipsel=2.6.2%7Epre%2Bgit20161223-1=1482523419=log
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Justin Pettit 

Thank you.  I applied this to master and branch-2.6.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

[Ben Mack-Crane]

Re: Discussed introduction of a new OXM class for the proposed GEN_TLV
fields

   - No problem to reserve an OXM class even before those fields are
   standardized


We have allocated OXM class 0x8005 for TLV value mapping (experimental for
now) in the ONF Registry
.

Regards,
Ben

On Thu, Dec 22, 2016 at 4:51 AM, Jan Scheurich 
wrote:

> Thanks for the good meeting. Here are my notes:
>
> Date: 2016-12-21, 17-18:30 CET
> Participants: Jarno R, Ben P, Ben M-C, Jiri B, Simon H, Zoltan B, Jan S
>
> Summary:
>
>- Discussed making PTAP, EXT-382 and NSH available as extensions to OF
>1.3.
>
>
>- No big deal for the match fields and the encap/decap actions
>- Potential problem could be the missing packet_type information in OF
>1.3 Packet In, Packet Out and Table Features (Note: Closer inspection of OF
>1.5.1 spec reveals that OXM packet_type is part of struct ofp_match in
>Packet In and Packet Out. It should be OK for an OF 1.3 controller extended
>with PTAP support)
>- Is it simpler for the controllers to upgrade to OF 1.5?
>- Deferred the decision
>
>
>- Agreed to use the (to be assigned) OXM field code points for
>packet_type and NSH in OVS for all OF versions
>- Agreed to allow all NS=1 packet types received from/sent to a tunnel
>port that uses the Ethertype name space in its protocol field (like GRE).
>Other versatile tunnel ports (like VXLAN-GPE) which have their own code
>points require explicit mapping and must drop packets for which no such
>mapping exists.
>- Discussed introduction of a new OXM class for the proposed GEN_TLV
>fields
>
>
>- No problem to reserve an OXM class even before those fields are
>standardized
>- For standardization we also need to specify a dynamic binding
>mechanism between protocol TLVs and GEN_TLV fields. We can submit the
>mechanism to be developed in OVS for standardization when its stable.
>
>
>- Walk-through of division into work packages:
>
>
>- Some follow up needed for the L3 packet support kernel datapath
>patches
>- Rest OK
>- Technical discussion around GEN_TLV and use for NSH MD2 in
>conjunction with encap(NSH) to be continued in the Google doc.
>
>
>- Time line:
>
>
>- The entire work should be targeting OVS 2.8 with feature freeze
>around July
>
>
>- OVS 2.7 is having feature freeze already in early January
>
>
>- Work packages can be upstreamed individually. NSH MD1 support
>doesn’t have to wait for MD2
>
>
>- Basically agreed to the work split proposed in the document:
>
>
>- RedHat is taking the patches for L3 tunnel configuration (including
>use of RTNETLINK for config)
>- Ericsson take the infrastructure components (L3-tunnels, PTAP, Basic
>EXT-382)
>- Jarno (VMware) will handle the GEN_TLV infrastructure
>- Confirm with Yi Yang (Intel): Can they take VXLAN-GPE and the
>NSH-specific WPs? Or do they need help?
>
>
>- Way of working
>
>
>- Continue the meeting series for coordination of effort
>- Can use a feature integration branch to ease the joint development
>and test
>- Review of patches mainly through the ovs-dev mailing list
>- Use tools like git citool to break up larger patches into a series
>of smaller patches for review
>
>
>
>
> -Original Appointment-
> *From:* Jan Scheurich
> *Sent:* Sunday, 18 December, 2016 15:34
> *To:* Jan Scheurich; Zoltán Balogh; Yang, Yi Y (yi.y.y...@intel.com);
> Jiri Benc (jb...@redhat.com); Pravin Shelar; Simon Horman (
> simon.hor...@netronome.com); jpet...@ovn.org; ja...@ovn.org; Ben Pfaff; '
> ben.mackcr...@corsa.com'; d...@openvswitch.org
> *Subject:* Sync on PTAP, EXT-382 and NSH
> *When:* Wednesday, 21 December, 2016 17:00-18:30 (UTC+01:00) Amsterdam,
> Berlin, Bern, Rome, Stockholm, Vienna.
> *Where:* Skype Meeting
>
>
> Moved to Wednesday same time to accommodate Jiri.
> Hope this is still OK for the others.
>
>
> Hello all,
>
> I would like to call for a final sync meeting before the Christmas break.
>
> Now that we have gone through the main aspects of the design, I would like
> to focus on how to divide the entire function into manageable pieces,
> discuss the potential work split, an integration anatomy and a rough time
> plane for upstreaming. I will try to prepare input in our Google doc for
> this.
>
>
> *https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit*
> 
>
> If there are questions left regarding the design, please bring them up as
> well. You can also comment on the document at any time.
>
> Regards, Jan
>
> 
> 
> .
> à *Join Skype Meeting* 

[ovs-dev] [RFC] make: Check for Sphinx before checking docs

[Stephen Finucane]

Signed-off-by: Stephen Finucane 
---
I can't get this to work. I'm getting the following error message:

  Documentation/automake.mk:106: error: HAVE_SPHINX does not appear in 
AM_CONDITIONAL
---
 Documentation/automake.mk |  4 +++-
 m4/openvswitch.m4 | 14 +-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index b27ad13..1e7589c 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -103,7 +103,9 @@ htmldocs:
rm -rf $(SPHINXBUILDDIR)/*
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/html
 
-.PHONY: docs-check
+if HAVE_SPHINX
 ALL_LOCAL += docs-check
 docs-check:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) -q 
$(SPHINXBUILDDIR)/linkcheck
+CLEANFILES += docs-check
+endif
diff --git a/m4/openvswitch.m4 b/m4/openvswitch.m4
index a448223..d49adf2 100644
--- a/m4/openvswitch.m4
+++ b/m4/openvswitch.m4
@@ -400,7 +400,7 @@ else:
AM_CONDITIONAL([HAVE_PYTHON3], [test "$HAVE_PYTHON3" = yes])])
 
 
-dnl Checks for dot.
+dnl Checks for flake8.
 AC_DEFUN([OVS_CHECK_FLAKE8],
   [AC_CACHE_CHECK(
 [for flake8],
@@ -412,6 +412,18 @@ AC_DEFUN([OVS_CHECK_FLAKE8],
  fi])
AM_CONDITIONAL([HAVE_FLAKE8], [test "$ovs_cv_flake8" = yes])])
 
+dnl Checks for sphinx.
+AC_DEFUN([OVS_CHECK_SPHINX],
+  [AC_CACHE_CHECK(
+[for sphinx-build],
+[ovs_cv_sphinx],
+[if sphinx-build --version >/dev/null 2>&1; then
+   ovs_cv_sphinx=yes
+ else
+   ovs_cv_sphinx=no
+ fi])
+   AM_CONDITIONAL([HAVE_SPHINX], [test "$ovs_cv_sphinx" = yes])])
+
 dnl Checks for dot.
 AC_DEFUN([OVS_CHECK_DOT],
   [AC_CACHE_CHECK(
-- 
2.9.3

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

[ovs-dev] [PATCH 1/2] docs: Resolve broken URLs

[Stephen Finucane]

These were found using the 'linkcheck' builder.

Signed-off-by: Stephen Finucane 
Cc: Ben Pfaff 
---
 Documentation/faq/openflow.rst  |  2 +-
 Documentation/faq/vlan.rst  |  4 ++--
 Documentation/faq/vxlan.rst |  2 +-
 Documentation/howto/dpdk.rst|  2 +-
 Documentation/internals/contributing/coding-style.rst   |  2 +-
 .../internals/contributing/documentation-style.rst  |  2 +-
 .../internals/contributing/submitting-patches.rst   |  6 +++---
 Documentation/internals/security.rst| 17 +
 Documentation/intro/install/general.rst |  4 ++--
 Documentation/intro/install/windows.rst |  2 +-
 Documentation/topics/testing.rst|  2 +-
 Documentation/topics/windows.rst| 16 
 Documentation/tutorials/ovn-basics.rst  |  4 ++--
 13 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/Documentation/faq/openflow.rst b/Documentation/faq/openflow.rst
index e9a3a74..abe89c6 100644
--- a/Documentation/faq/openflow.rst
+++ b/Documentation/faq/openflow.rst
@@ -523,7 +523,7 @@ Q: The "learn" action can't learn the action I want, can 
you improve it?
 example:
 
 - Resubmit to a table selected based on learned information, e.g. see:
-  http://openvswitch.org/pipermail/discuss/2016-June/021694.html
+  https://mail.openvswitch.org/pipermail/ovs-discuss/2016-June/021694.html
 
 - MAC learning in the middle of a pipeline, as described in
   :doc:`/tutorials/ovs-advanced`
diff --git a/Documentation/faq/vlan.rst b/Documentation/faq/vlan.rst
index 0024ce8..3b09d89 100644
--- a/Documentation/faq/vlan.rst
+++ b/Documentation/faq/vlan.rst
@@ -206,8 +206,8 @@ but other hosts that are only on VLAN 0 can reach the IP 
address configured on
 VLAN 9.  What's going on?
 
 A: `RFC 1122 section 3.3.4.2 "Multihoming Requirements"
-`__ describes two
-approaches to IP address handling in Internet hosts:
+`__ describes two approaches to IP
+address handling in Internet hosts:
 
 - In the "Strong ES Model", where an ES is a host ("End System"), an IP
   address is primarily associated with a particular interface.  The host
diff --git a/Documentation/faq/vxlan.rst b/Documentation/faq/vxlan.rst
index 966f79e..c036ffd 100644
--- a/Documentation/faq/vxlan.rst
+++ b/Documentation/faq/vxlan.rst
@@ -31,7 +31,7 @@ Q: What's a VXLAN?
 to solve the scaling challenges of VLAN networks in a multi-tenant
 environment. VXLAN is an overlay network which transports an L2 network
 over an existing L3 network. For more information on VXLAN, please see `RFC
-7348 `__.
+7348 `__.
 
 Q: How much of the VXLAN protocol does Open vSwitch currently support?
 
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index f55ae3b..e96ce56 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -224,7 +224,7 @@ tcpdump. Issue the following command to view the contents 
of ``pkts.pcap``::
 $ tcpdump -r pkts.pcap
 
 More information on the pdump app and its usage can be found in the `DPDK docs
-`__.
+`__.
 
 Jumbo Frames
 
diff --git a/Documentation/internals/contributing/coding-style.rst 
b/Documentation/internals/contributing/coding-style.rst
index 8410064..e62f5e3 100644
--- a/Documentation/internals/contributing/coding-style.rst
+++ b/Documentation/internals/contributing/coding-style.rst
@@ -638,5 +638,5 @@ Python
 --
 
 When introducing new Python code, try to follow Python's `PEP 8
-`__ style. Consider running the
+`__ style. Consider running the
 ``pep8`` or ``flake8`` tool against your code to find issues.
diff --git a/Documentation/internals/contributing/documentation-style.rst 
b/Documentation/internals/contributing/documentation-style.rst
index ef0e0e7..ea41a07 100644
--- a/Documentation/internals/contributing/documentation-style.rst
+++ b/Documentation/internals/contributing/documentation-style.rst
@@ -365,4 +365,4 @@ Useful Links
 - `Quick reStructuredText
   `__
 
-- `Sphinx Documentation `__
+- `Sphinx Documentation `__
diff --git a/Documentation/internals/contributing/submitting-patches.rst 
b/Documentation/internals/contributing/submitting-patches.rst
index 9fb7785..36e3b17 100644
--- 

[ovs-dev] [PATCH 2/2] make: Add 'doc-check' target

[Stephen Finucane]

This does basic validation of the syntax and validates all external
links.

The nitpick ('-n') flag is added to ensure all possible warnings are
raised.

Signed-off-by: Stephen Finucane 
Cc: Ben Pfaff 
---
 Documentation/automake.mk | 7 ++-
 Documentation/conf.py | 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 98adca7..b27ad13 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -96,9 +96,14 @@ SPHINXBUILDDIR = $(builddir)/Documentation/_build
 # Internal variables.
 PAPEROPT_a4 = -D latex_paper_size=a4
 PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -W -d $(SPHINXBUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) 
$(SPHINXOPTS) $(SPHINXSRCDIR)
+ALLSPHINXOPTS = -W -n -d $(SPHINXBUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) 
$(SPHINXOPTS) $(SPHINXSRCDIR)
 
 .PHONY: htmldocs
 htmldocs:
rm -rf $(SPHINXBUILDDIR)/*
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/html
+
+.PHONY: docs-check
+ALL_LOCAL += docs-check
+docs-check:
+   $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) -q 
$(SPHINXBUILDDIR)/linkcheck
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 63f5877..06f50bc 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -113,6 +113,8 @@ pygments_style = 'sphinx'
 # If true, `todo` and `todoList` produce output, else they produce nothing.
 todo_include_todos = False
 
+# If true, check the validity of #anchors in links.
+linkcheck_anchors = False
 
 # -- Options for HTML output --
 
-- 
2.9.3

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

Re: [ovs-dev] [PATCH] debian: Also restrict ovn-docker package to Linux.

[Justin Pettit]

> On Dec 23, 2016, at 1:45 PM, Ben Pfaff  wrote:
> 
> The Debian packages for OVS have only supported Linux so far, but the
> ovn-docker package was mistakenly marked as Architecture: any instead
> of linux-any, which caused build failures.  This fixes the problem.
> 
> (Perhaps OVS packaging for Debian should also support BSD, but that
> would be a bigger change.)
> 
> Reported-at: 
> https://buildd.debian.org/status/fetch.php?pkg=openvswitch=kfreebsd-amd64=2.6.2%7Epre%2Bgit20161223-1=1482518318=log
> Signed-off-by: Ben Pfaff 

Acked-by: Justin Pettit 

--Justin




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

Re: [ovs-dev] [PATCH] tests: Fix race in "ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS".

[Justin Pettit]

> On Dec 23, 2016, at 1:34 PM, Ben Pfaff  wrote:
> 
> The 1-second sleep to wait for the bind to occur is not long enough on
> slow mips machines.  This fixes the problem.
> 
> Reported-at: 
> https://buildd.debian.org/status/fetch.php?pkg=openvswitch=mipsel=2.6.2%7Epre%2Bgit20161223-1=1482523419=log
> Signed-off-by: Ben Pfaff 

Acked-by: Justin Pettit 

--Justin




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

Re: [ovs-dev] [PATCH] packets: Simplify packet_csum_pseudoheader6().

[Andy Zhou]

On Fri, Dec 23, 2016 at 9:06 AM, Ben Pfaff  wrote:

> It's simpler to make two calls than eight.
>
> Reported-by: Eelco Chaudron 
> Signed-off-by: Ben Pfaff 


Acked-by: Andy Zhou 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] debian: Also restrict ovn-docker package to Linux.

[Ben Pfaff]

The Debian packages for OVS have only supported Linux so far, but the
ovn-docker package was mistakenly marked as Architecture: any instead
of linux-any, which caused build failures.  This fixes the problem.

(Perhaps OVS packaging for Debian should also support BSD, but that
would be a bigger change.)

Reported-at: 
https://buildd.debian.org/status/fetch.php?pkg=openvswitch=kfreebsd-amd64=2.6.2%7Epre%2Bgit20161223-1=1482518318=log
Signed-off-by: Ben Pfaff 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 813721a..0b75f2b 100644
--- a/debian/control
+++ b/debian/control
@@ -161,7 +161,7 @@ Description: OVN central components
  databases for OVN that is run at a central location.
 
 Package: ovn-docker
-Architecture: any
+Architecture: linux-any
 Depends: openvswitch-switch (= ${binary:Version}),
  openvswitch-common (= ${binary:Version}),
  python (>= 2.7),
-- 
2.10.2

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

Re: [ovs-dev] [PATCH v2] Windows: Implement Hyper-V VIF discovery agent.

[Shashank Ram]

Hi Yin, thanks for your changes. Would it be possible for you to split this 
feature into smaller, easier to review commits?


Also, please also mention in the commit message how you tested out different 
scenarios, and what will be the impact on existing Vif addition workflow etc.


Thanks!


From: ovs-dev-boun...@openvswitch.org  on 
behalf of Yin Lin 
Sent: Monday, December 12, 2016 2:20:51 PM
To: d...@openvswitch.org
Subject: [ovs-dev] [PATCH v2] Windows: Implement Hyper-V VIF discovery agent.

Signed-off-by: Yin Lin 
---
 windows/OvsDiscoveryAgent/App.config   |  18 ++
 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj |  83 
 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln|  34 +++
 windows/OvsDiscoveryAgent/OvsDiscoveryService.cs   |  67 ++
 windows/OvsDiscoveryAgent/OvsSwitchMonitor.cs  |  73 +++
 windows/OvsDiscoveryAgent/OvsVsctl.cs  |  82 
 windows/OvsDiscoveryAgent/Program.cs   |  26 +++
 .../OvsDiscoveryAgent/Properties/AssemblyInfo.cs   |  36 
 .../Properties/Settings.Designer.cs|  38 
 .../OvsDiscoveryAgent/Properties/Settings.settings |   9 +
 windows/OvsDiscoveryAgent/VirtualAdapter.cs|  36 
 windows/OvsDiscoveryAgent/VirtualAdapterManager.cs | 228 +
 windows/OvsDiscoveryAgent/VirtualAdapterMonitor.cs | 109 ++
 windows/OvsDiscoveryAgent/WmiMonitor.cs| 193 +
 windows/OvsDiscoveryAgent/WqlCondition.cs  | 168 +++
 windows/OvsDiscoveryAgent/WqlHelper.cs | 130 
 windows/OvsDiscoveryAgent/WqlObject.cs | 133 
 windows/automake.mk|  21 ++
 18 files changed, 1484 insertions(+)
 create mode 100644 windows/OvsDiscoveryAgent/App.config
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryService.cs
 create mode 100644 windows/OvsDiscoveryAgent/OvsSwitchMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/OvsVsctl.cs
 create mode 100644 windows/OvsDiscoveryAgent/Program.cs
 create mode 100644 windows/OvsDiscoveryAgent/Properties/AssemblyInfo.cs
 create mode 100644 windows/OvsDiscoveryAgent/Properties/Settings.Designer.cs
 create mode 100644 windows/OvsDiscoveryAgent/Properties/Settings.settings
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapter.cs
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapterManager.cs
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapterMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/WmiMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlCondition.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlHelper.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlObject.cs

diff --git a/windows/OvsDiscoveryAgent/App.config 
b/windows/OvsDiscoveryAgent/App.config
new file mode 100644
index 000..caf9613
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/App.config
@@ -0,0 +1,18 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ovs-int
+
+
+
+
\ No newline at end of file
diff --git a/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj 
b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
new file mode 100644
index 000..24c69bb
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
@@ -0,0 +1,83 @@
+
+https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.microsoft.com_developer_msbuild_2003=DgIFaQ=uilaK90D4TOVoH58JNXRgQ=6OuVHk-mnufSWzkKa74UkQ=1xklhz_AUTMCHdJjqAkgoYBWaBfNudcFfaNpo8CBYU8=k3L9MzpvSg_ihGUKIhnwvJN2YQVsSq8COkkuku2vLlg=
 ">
+  
+  
+Debug
+AnyCPU
+{2563C1BE-B240-4F63-84C5-01D98D015A3F}
+Exe
+Properties
+OvsDiscoveryAgent
+OvsDiscoveryAgent
+v4.5.2
+512
+true
+  
+  
+AnyCPU
+true
+full
+false
+bin\Debug\
+DEBUG;TRACE
+prompt
+4
+  
+  
+AnyCPU
+pdbonly
+true
+bin\Release\
+TRACE
+prompt
+4
+  
+  
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+  True
+  True
+  Settings.settings
+
+
+
+  Component
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+  SettingsSingleFileGenerator
+  Settings.Designer.cs
+
+  
+  
+  
+
\ No newline at end of file
diff --git a/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln 
b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
new file mode 100644
index 000..b3d6371
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
@@ -0,0 +1,34 @@
+
+Microsoft Visual Studio Solution File, Format Version 12.00
+# Visual Studio 14
+VisualStudioVersion = 14.0.25123.0

[ovs-dev] [PATCH] tests: Fix race in "ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS".

[Ben Pfaff]

The 1-second sleep to wait for the bind to occur is not long enough on
slow mips machines.  This fixes the problem.

Reported-at: 
https://buildd.debian.org/status/fetch.php?pkg=openvswitch=mipsel=2.6.2%7Epre%2Bgit20161223-1=1482523419=log
Signed-off-by: Ben Pfaff 
---
 tests/ovn.at | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/ovn.at b/tests/ovn.at
index 557b2ca..b7cb4cb 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -1773,9 +1773,7 @@ vtep-ctl add-ls lsw0
 start_daemon ovs-vtep br-vtep
 start_daemon ovn-controller-vtep --vtep-db=unix:"$ovs_base"/vtep/db.sock 
--ovnsb-db=unix:"$ovs_base"/ovn-sb/ovn-sb.sock
 
-sleep 1
-
-vtep-ctl bind-ls br-vtep br-vtep_n2 0 lsw0
+OVS_WAIT_UNTIL([vtep-ctl bind-ls br-vtep br-vtep_n2 0 lsw0])
 
 OVS_WAIT_UNTIL([test -n "`as vtep vtep-ctl get-replication-mode lsw0 |
grep -- source`"])
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] ovn: Cache mac bindings from broadcasted dynamic ARP responses

[Ben Pfaff]

On Thu, Dec 22, 2016 at 05:06:08PM +0530, Babu Shanmugam wrote:
> This patch attempts to avoid the usage of MAC_Binding table.
> 
> Dynamic ARP response originates from the logical ports with "unknown"
> address. When the ARP resolution is requested via a logical
> router datapath, ARP response will be delivered to the logical router
> port of the switch. Since the logical router is distributed, the
> response will never reach the other chassis from where the ARP resolution
> is requested.
> 
> This is done using a OVN logical action bcast2lr() which adds an action
> to send the packet to a specific multicast group for the logical router
> datapath. For the chassis that have an "unknown" port connected to any
> logical router, the bcast2lr() action will do the broadcast. The other
> chassis will listen for such broadcast packets and executes put_arp()
> action on them.
> 
> When the ovn-controller processes put_arp() action, it caches the MAC
> bindings and this cache will be used to update the openflow table used
> for the dynamic MAC resolution
> 
> Signed-off-by: Babu Shanmugam 

Thanks for the patch.  We need a solution for this problem, and this is
the first real attempt I've seen.

Clang says:

../ovn/lib/actions.c:1672:9: error: variable 'dp_id' is used uninitialized 
whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
../ovn/lib/actions.c:1699:23: note: uninitialized use occurs here
../ovn/lib/actions.c:1672:5: note: remove the 'if' if its condition is 
always true
../ovn/lib/actions.c:1667:15: note: initialize the variable 'dp_id' to 
silence this warning
../ovn/lib/actions.c:1672:9: error: variable 'chassis' is used 
uninitialized whenever 'if' condition is false 
[-Werror,-Wsometimes-uninitialized]
../ovn/lib/actions.c:1700:22: note: uninitialized use occurs here
../ovn/lib/actions.c:1672:5: note: remove the 'if' if its condition is 
always true
../ovn/lib/actions.c:1669:18: note: initialize the variable 'chassis' to 
silence this warning
../ovn/lib/actions.c:1672:9: error: variable 'port_key' is used 
uninitialized whenever 'if' condition is false 
[-Werror,-Wsometimes-uninitialized]
../ovn/lib/actions.c:1701:26: note: uninitialized use occurs here
../ovn/lib/actions.c:1672:5: note: remove the 'if' if its condition is 
always true
../ovn/lib/actions.c:1668:18: note: initialize the variable 'port_key' to 
silence this warning
../ovn/lib/actions.c:1672:9: error: variable 'is_this_chassis' is used 
uninitialized whenever 'if' condition is false 
[-Werror,-Wsometimes-uninitialized]
../ovn/lib/actions.c:1702:30: note: uninitialized use occurs here
../ovn/lib/actions.c:1672:5: note: remove the 'if' if its condition is 
always true
../ovn/lib/actions.c:1670:25: note: initialize the variable 
'is_this_chassis' to silence this warning
../ovn/lib/actions.c:1709:19: error: format specifies type 'long' but the 
argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
../ovn/northd/ovn-northd.c:3144:25: error: format specifies type 'long' but 
the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat]
../ovn/northd/ovn-northd.c:3145:25: error: format specifies type 'long' but 
the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat]

GCC says:

../ovn/lib/actions.c: In function 'format_BCAST2LR':
../ovn/lib/actions.c:1708:41: error: format '%ld' expects argument of type 
'long int', but argument 3 has type 'uint64_t {aka const long long unsigned 
int}' [-Werror=format=]
 ds_put_format(s, "bcast2lr(dst_dp=%ld, dst_pkey=%d, chassis=\"%s\");",
 ^
../ovn/lib/actions.c: In function 'parse_action':
../ovn/lib/actions.c:1702:28: error: 'is_this_chassis' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 bc2lr->is_this_chassis = is_this_chassis;
 ~~~^
../ovn/lib/actions.c:1670:10: note: 'is_this_chassis' was declared here
 bool is_this_chassis;
  ^~~
../ovn/lib/actions.c:1700:20: error: 'chassis' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
 bc2lr->chassis = chassis;
 ~~~^
../ovn/lib/actions.c:1669:11: note: 'chassis' was declared here
 char *chassis;
   ^~~
../ovn/northd/ovn-northd.c: In function ‘build_lswitch_flows’:
../ovn/northd/ovn-northd.c:3142:44: error: format ‘%ld’ expects argument of 
type ‘long int’, but argument 3 has type ‘int64_t {aka const long long int}’ 
[-Werror=format=]
 "bcast2lr(dst_dp=%ld, dst_pkey=%ld, 
chassis=\"%s\");"
^
../ovn/northd/ovn-northd.c:3142:58: error: format ‘%ld’ expects argument of 
type ‘long int’, but argument 4 has type ‘int64_t {aka const long long int}’ 

Re: [ovs-dev] [PATCH] rconn: Avoid abort for ill-behaved remote.

[Justin Pettit]

> On Dec 23, 2016, at 9:23 AM, Ben Pfaff  wrote:
> 
> If an rconn peer fails to send a hello message, the version number doesn't
> get set.  Later, if the peer delays long enough, the rconn attempts to send
> an echo request but assert-fails instead because it doesn't know what
> version to use.  This fixes the problem.
> 
> To reproduce this problem:
> 
>make sandbox
>ovs-vsctl add-br br0
>ovs-vsctl set-controller br0 ptcp:12345
>nc 127.0.0.1 12345
> 
> and wait 10 seconds for ovs-vswitchd to die.  (Then exit the sandbox.)
> 
> Reported-by: 张东亚 
> Signed-off-by: Ben Pfaff 

Acked-by: Justin Pettit 

--Justin




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

Re: [ovs-dev] [PATCH] doc: Correct type of highlighting

[Ben Pfaff]

On Fri, Dec 23, 2016 at 06:50:41PM +, Stephen Finucane wrote:
> On Fri, 2016-12-23 at 08:54 -0800, Ben Pfaff wrote:
> > I've been toying with the idea that the build should break if there
> > are
> > any broken links (at least internal links) in the .rst files.  Is
> > there
> > a practical way to make that happen?
> 
> Any internal references (using the 'doc:' or 'ref:' roles) do raise a
> warnings if the link's broken. This will cause a broken local build
> because warnings are treated as errors, but ReadTheDocs is less
> stringent (presumably to ensure docs are available as much as
> possible). I guess we could change this but it would only serve to
> highlight issues once they've already been committed. A better approach
> would be to always build the docs locally before committing them to
> highlight potential issues, but this is easily forgotten (as seen in
> this instance). Any ideas how we could automate this?

We have several targets that run on every plain "make" to check various
correctness and style properties.  For example, take a look at the
manpage-check and flake8-check targets in the top-level Makefile.am.  It
would be nice to add a similar target that checked the documentation, at
least in the case where the appropriate tools are installed.  Then any
developer who runs "make" (and has the tools) would find the issue
immediately, because the build would fail.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] doc: Correct type of highlighting

[Stephen Finucane]

On Fri, 2016-12-23 at 08:54 -0800, Ben Pfaff wrote:
> I've been toying with the idea that the build should break if there
> are
> any broken links (at least internal links) in the .rst files.  Is
> there
> a practical way to make that happen?

Any internal references (using the 'doc:' or 'ref:' roles) do raise a
warnings if the link's broken. This will cause a broken local build
because warnings are treated as errors, but ReadTheDocs is less
stringent (presumably to ensure docs are available as much as
possible). I guess we could change this but it would only serve to
highlight issues once they've already been committed. A better approach
would be to always build the docs locally before committing them to
highlight potential issues, but this is easily forgotten (as seen in
this instance). Any ideas how we could automate this?

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

[ovs-dev] Processing of openvswitch_2.6.2~pre+git20161223-1_i386.changes

[Debian FTP Masters]

openvswitch_2.6.2~pre+git20161223-1_i386.changes uploaded successfully to 
localhost
along with the files:
  openvswitch_2.6.2~pre+git20161223-1.dsc
  openvswitch_2.6.2~pre+git20161223.orig.tar.xz
  openvswitch_2.6.2~pre+git20161223-1.debian.tar.xz
  openvswitch-common_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-dbg_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-dev_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-ipsec_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-pki_2.6.2~pre+git20161223-1_all.deb
  openvswitch-switch_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-test_2.6.2~pre+git20161223-1_all.deb
  openvswitch-testcontroller_2.6.2~pre+git20161223-1_i386.deb
  openvswitch-vtep_2.6.2~pre+git20161223-1_i386.deb
  openvswitch_2.6.2~pre+git20161223-1_i386.buildinfo
  ovn-central_2.6.2~pre+git20161223-1_i386.deb
  ovn-common_2.6.2~pre+git20161223-1_i386.deb
  ovn-controller-vtep_2.6.2~pre+git20161223-1_i386.deb
  ovn-docker_2.6.2~pre+git20161223-1_i386.deb
  ovn-host_2.6.2~pre+git20161223-1_i386.deb
  python-openvswitch_2.6.2~pre+git20161223-1_all.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Bug#831924: marked as done (openvswitch: FTBFS with dpkg-buildpackage -A: cp: cannot create regular file 'debian/openvswitch-switch/usr/share/openvswitch/switch/default.template': No such fi

[Debian Bug Tracking System]

Your message dated Fri, 23 Dec 2016 18:19:09 +
with message-id 
and subject line Bug#831924: fixed in openvswitch 2.6.2~pre+git20161223-1
has caused the Debian Bug report #831924,
regarding openvswitch: FTBFS with dpkg-buildpackage -A: cp: cannot create 
regular file 
'debian/openvswitch-switch/usr/share/openvswitch/switch/default.template': No 
such file or directory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
831924: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831924
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rconn: Avoid abort for ill-behaved remote.

[Ben Pfaff]

If an rconn peer fails to send a hello message, the version number doesn't
get set.  Later, if the peer delays long enough, the rconn attempts to send
an echo request but assert-fails instead because it doesn't know what
version to use.  This fixes the problem.

To reproduce this problem:

make sandbox
ovs-vsctl add-br br0
ovs-vsctl set-controller br0 ptcp:12345
nc 127.0.0.1 12345

and wait 10 seconds for ovs-vswitchd to die.  (Then exit the sandbox.)

Reported-by: 张东亚 
Signed-off-by: Ben Pfaff 
---
 lib/rconn.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/lib/rconn.c b/lib/rconn.c
index 0c1812a..8a29864 100644
--- a/lib/rconn.c
+++ b/lib/rconn.c
@@ -558,19 +558,23 @@ run_ACTIVE(struct rconn *rc)
 {
 if (timed_out(rc)) {
 unsigned int base = MAX(rc->last_activity, rc->state_entered);
-int version;
-
 VLOG_DBG("%s: idle %u seconds, sending inactivity probe",
  rc->name, (unsigned int) (time_now() - base));
 
-version = rconn_get_version__(rc);
-ovs_assert(version >= 0 && version <= 0xff);
-
 /* Ordering is important here: rconn_send() can transition to BACKOFF,
  * and we don't want to transition back to IDLE if so, because then we
  * can end up queuing a packet with vconn == NULL and then *boom*. */
 state_transition(rc, S_IDLE);
-rconn_send__(rc, make_echo_request(version), NULL);
+
+/* Send an echo request if we can.  (If version negotiation is not
+ * complete, that is, if we did not yet receive a "hello" message from
+ * the peer, we do not know the version to use, so we don't send
+ * anything.) */
+int version = rconn_get_version__(rc);
+if (version >= 0 && version <= 0xff) {
+rconn_send__(rc, make_echo_request(version), NULL);
+}
+
 return;
 }
 
-- 
2.10.2

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

Re: [ovs-dev] [PATCH v2 1/2] sflow: restrict sampling from 1 to UINT32_MAX

[Ben Pfaff]

On Thu, Dec 22, 2016 at 09:58:00PM -0800, Benli Ye wrote:
> When sampling field is 0, no need to generate sample or
> the inner action.
> 
> Signed-off-by: Benli Ye 

Thanks for the updated patches.  I applied them to master.

I made some stylistic fixes in patch 2.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] 答复: ovn-nbctl: Not Specify the type of Logical switch port.

[Ben Pfaff]

Thanks for the patch.  I don't think that this patch adds much value,
and it would increase the maintenance burden as OVN adds support for new
types of ports.  I don't think that we should apply it.

In addition, this patch is word-wrapped.  In the future, please use "git
send-email" to avoid sending corrupted patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovn-nbctl]:The range of "PRIORITY" for "ovn-nbctl acl-add " command is wrong.

[Ben Pfaff]

Thanks for the patch.  It's word-wrapped and cannot be applied.  Can you
re-send?  Please try to use "git send-email", which always properly
formats a patch.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Adding IGMP/MLD checksum verification

[Ben Pfaff]

On Fri, Dec 23, 2016 at 10:31:19AM +0100, Eelco Chaudron wrote:
> On 22/12/16 17:14, Ben Pfaff wrote:
> >On Wed, Dec 14, 2016 at 07:08:27PM +0100, Eelco Chaudron wrote:
> >>When IGMP or MLD packets arrive their content is used without the checksum
> >>being verified. With this change the checksum is verified, and the packet
> >>is not used for multicast snooping on failure.
> >>
> >>Signed-off-by: Eelco Chaudron 
> >Thanks for the patch!  I applied it to master.  I folded in the
> >following simplification, which I believe to be correct and also passes
> >the test.  Please let me know if you see a problem.
> Thanks, your change is fine. I just mimicked the code above my change.

Oh, I hadn't noticed that.  I think it's best to adjust that code too.
I sent out a patch for review.

> >Also, I believe that this is your first contribution to Open vSwitch.
> >Thank you for helping, and welcome to the team!
> Yes this is my first patch, but I'm planning on doing a lot more next year!

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

[ovs-dev] [PATCH] packets: Simplify packet_csum_pseudoheader6().

[Ben Pfaff]

It's simpler to make two calls than eight.

Reported-by: Eelco Chaudron 
Signed-off-by: Ben Pfaff 
---
 lib/packets.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/lib/packets.c b/lib/packets.c
index 748418b..13a063a 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -1459,16 +1459,8 @@ packet_csum_pseudoheader6(const struct 
ovs_16aligned_ip6_hdr *ip6)
 {
 uint32_t partial = 0;
 
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_src.be32[0])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_src.be32[1])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_src.be32[2])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_src.be32[3])));
-
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_dst.be32[0])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_dst.be32[1])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_dst.be32[2])));
-partial = csum_add32(partial, get_16aligned_be32(&(ip6->ip6_dst.be32[3])));
-
+partial = csum_continue(partial, >ip6_src, sizeof ip6->ip6_src);
+partial = csum_continue(partial, >ip6_dst, sizeof ip6->ip6_dst);
 partial = csum_add16(partial, htons(ip6->ip6_nxt));
 partial = csum_add16(partial, ip6->ip6_plen);
 
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] doc: Correct type of highlighting

[Ben Pfaff]

On Fri, Dec 23, 2016 at 11:46:29AM +, Stephen Finucane wrote:
> Some recent changes marked code as Powershell when in fact it was DOS or
> bash shell. This incorrect highlighting actually breaks the local build
> (where warnings are treated as errors) as pygments is unable to lex all
> the code as PowerShell. Fix these types.
> 
> Signed-off-by: Stephen Finucane 
> Fixes: b8d24cc8a ("doc: Misc Windows doc formatting fixes")

Thanks!  Applied to master.

I've been toying with the idea that the build should break if there are
any broken links (at least internal links) in the .rst files.  Is there
a practical way to make that happen?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3] tests: Ignore options order in dhcpv4 ovn test.

[Balazs Nemeth]

>On 14/12/2016 06:38, "Balazs Nemeth"  wrote:
>
>>>On 12/12/2016 13:14, "Ben Pfaff"  wrote:
>>>
On Thu, Dec 08, 2016 at 06:50:32PM -0800, Daniele Di Proietto wrote:
> The order of the options in the packet generated by ovs-controller
> depends on the hash function.  I believe that murmur hash (our default)
> produces different outputs depending on the endianness of the system.
>
> This commit fixes the test by reordering the options in the packet
> before checking them.
>
> This was reported before as a failure of the test on x86 with sse42
> enabled, I'm fixing it now because it affects other targets build by
> distros by default.
>
> Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840770
> Signed-off-by: Daniele Di Proietto 

I agree that this would solve the problem.

I think that it might be nicer to instead sort the options in
build_dhcpv4_action() and build_dhcpv6_action() in ovn-northd.c.  Then
the generated logical actions won't differ from one architecture to
another, so that if we one day push a test to a higher level we won't
have an underlying source of differences.  There's even a helper
smap_sort() that could do most of the work.

Are you willing to make that change?
>>>
>>>Sure, it's better than parsing TLVs with awk.  I'll send a v2.
>>>
>>>Thanks,
>>>
>>>Daniele
>>>

Thanks,

Ben.
>>
>>
>>Hi Daniele,
>>
>>I applied this patch on top of branch-2.6 (which is including 1/3 and 2/3 
>>patch). I built OVS with SSE4.2 flag. UT 2246 is still failing
>> due to only 571st char of 'packets' and 'expected' files are compared and 
>> those are different in case of CRC32 hash. The following patch will fix the 
>> failing UT in case of build without any extra flag or with SSE4.2 as well:
>>
>>diff --git a/tests/ovn.at b/tests/ovn.at
>>index 8b1228f..3f4c6cf 100644
>>--- a/tests/ovn.at
>>+++ b/tests/ovn.at
>>@@ -3724,8 +3724,8 @@ AT_CHECK([cat 1.packets | cut -c 53-570], [0], [expout])
>># The ordering of the options in the packet depends on the hash function used
>># and possibly on the endianness of the system.  We parse and sort both the
>># expected and the generated packet.
>>-cat 1.expected | cut -c 571 | sort_dhcpv4opts_tlv > expout
>>-AT_CHECK([cat 1.packets | cut -c 571 | sort_dhcpv4opts_tlv], [0], [expout])
>>+cat 1.expected | cut -c 571- | sort_dhcpv4opts_tlv > expout
>>+AT_CHECK([cat 1.packets | cut -c 571- | sort_dhcpv4opts_tlv], [0], [expout])
>>
>># ovs-ofctl also resumes the packets and this causes other ports to receive
>># the DHCP request packet. So reset the pcap files so that its easier to test.
>>@@ -3752,8 +3752,8 @@ AT_CHECK([cat 2.packets | cut -c 53-570], [0], [expout])
>># The ordering of the options in the packet depends on the hash function used
>># and possibly on the endianness of the system.  We parse and sort both the
>># expected and the generated packet.
>>-cat 2.expected | cut -c 571 | sort_dhcpv4opts_tlv > expout
>>-AT_CHECK([cat 2.packets | cut -c 571 | sort_dhcpv4opts_tlv], [0], [expout])
>>+cat 2.expected | cut -c 571- | sort_dhcpv4opts_tlv > expout
>>+AT_CHECK([cat 2.packets | cut -c 571- | sort_dhcpv4opts_tlv], [0], [expout])
>>
>>reset_pcap_file hv1-vif1 hv1/vif1
>>reset_pcap_file hv1-vif2 hv1/vif2
>
>Hi Balazs,
>
>I think you're right, I was only cutting the 571st character, thanks for 
>spotting the error.
>
>Anyway, we decided to drop this patch, go with another approach and sort the 
>options in the program, not in the test:
>
>https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326133.html
>
>I already merged this to master:
>
>7c76bf4e0e27 ("ovn-northd: Sort options in put_dhcp(v6)_opts.")
>
>and branch-2.6:
>
>cbd39073245e ("ovn-northd: Sort options in put_dhcp(v6)_opts.")
>
>Can you try latest master and branch-2.6 without any other patch applied?
>
>It seems to pass for me on x86_64 x86_64+sse4.2 and mips.
>
>Thanks,
>
>Daniele

Hi Daniele,

Yes, I tried with the latest master and branch-2.6 including the mentioned 
patch. All TC is successful with/without SSE 4.2 support as well.
Thank you. Also my question on discuss list with topic "Failing UT 2246 in case 
of build with SSE4.2 support" is closed now.

BR,
Balazs
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] lacp: Select a may-enable IF as the lead IF

[Torgny Lindberg]

On Wed Dec 21 17:27:05 UTC 2016, Ben Pfaff wrote:
> On Thu, Dec 01, 2016 at 02:01:59PM +0100, Torgny Lindberg wrote:
> > A reboot of one switch in an MC-LAG bond makes all bond links
> > to go down, causing a total connectivity loss for 3 seconds.
> >
> > Packet capture shows that spurious LACP PDUs are sent to OVS with
> > a different MAC address (partner system id) during the final
> > stages of the MC-LAG switch reboot.
> >
> > The current code selects a lead interface based on information
> > in the LACP PDU, regardless of its synchronization state. If a
> > non-synchronized interface is selected as the OVS lead interface
> > then all other interfaces are forced down as their stored partner
> > system id differs and the bond ends up with no working interface.
> > The bond recovers within three seconds after the last spurious
> > message.
> >
> > To avoid the problem, this commit requires a lead interface
> > to be synchronized. In case no synchronized interface exists,
> > the selection of lead interface is done as in the current code.
> >
> > Signed-off-by: Torgny Lindberg 
> 
> I think I understand what's going on here now.  I made some changes that
> better reflect my understanding:
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-
> December/326567.html
> Does this work for you?  If so, I'll apply it.
> 
> Thanks,
> 
> Ben.

Hi Ben,


yes, the changed code gives the same result so it works for me.


Thanks,
Torgny



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

[ovs-dev] Estimado usuario

[Mr. X]

Estimado usuario

Su dirección de correo electrónico ha superado 2 GB creado por el webmaster, es 
que se están ejecutando en 2,30 GB, que no puede enviar o recibir un nuevo 
mensaje en las próximas 24 horas hasta que se comprueba si la cuenta de correo 
electrónico.

Por favor ingrese sus datos para verificar tu cuenta:

(1) correo electrónico:
(2) nombre:
(3) contraseña:
(4) Confirmar contraseña:

Gracias
El administrador del sistema
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v8] netdev-dpdk: Enable Rx checksum offloading feature on DPDK physical ports.

[Sugesh Chandran]

Add Rx checksum offloading feature support on DPDK physical ports. By default,
the Rx checksum offloading is enabled if NIC supports. However,
the checksum offloading can be turned OFF either while adding a new DPDK
physical port to OVS or at runtime.

The rx checksum offloading can be turned off by setting the parameter to
'false'. For eg: To disable the rx checksum offloading when adding a port,

 'ovs-vsctl add-port br0 dpdk0 -- \
  set Interface dpdk0 type=dpdk options:rx-checksum-offload=false'

OR (to disable at run time after port is being added to OVS)

'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=false'

Similarly to turn ON rx checksum offloading at run time,
'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=true'

The Tx checksum offloading support is not implemented due to the following
reasons.

1) Checksum offloading and vectorization are mutually exclusive in DPDK poll
mode driver. Vector packet processing is turned OFF when checksum offloading
is enabled which causes significant performance drop at Tx side.

2) Normally, OVS generates checksum for tunnel packets in software at the
'tunnel push' operation, where the tunnel headers are created. However
enabling Tx checksum offloading involves,

*) Mark every packets for tx checksum offloading at 'tunnel_push' and
recirculate.
*) At the time of xmit, validate the same flag and instruct the NIC to do the
checksum calculation.  In case NIC doesnt support Tx checksum offloading,
the checksum calculation has to be done in software before sending out the
packets.

No significant performance improvement noticed with Tx checksum offloading
due to the e overhead of additional validations + non vector packet processing.
In some test scenarios, it introduces performance drop too.

Rx checksum offloading still offers 8-9% of improvement on VxLAN tunneling
decapsulation even though the SSE vector Rx function is disabled in DPDK poll
mode driver.

Signed-off-by: Sugesh Chandran 
Acked-by: Jesse Gross 

---
v8
- Update error log to clearly mention when the checksum offload is unsupported.
- Rebase to OVS latest master.

v7
- Update documentation with details of performance impact of having DPDK
vectorization in disabled state.
- Merge to latest OVS master.

v6
- Avoid unnecessary reconfiguration of DPDK ports when Rx checksum offload
support is unavailable.
- Limit the 'Rx checksum offload is unsupported' message in logging.
- Merge to latest OVS for DPDK 16.11 support. The DPDK checksum flags that used
- in the patch are only introduced in 16.11.

v5
- Reset the checksum flag in common tunnel pop function than in
'udp_extract_tnl_md' function.

v4
- Unconditonally clear off the checksum flag one time in pop operation than
doing separately in IP and UDP layers.

v3
- Reset the checksum offload flags in tunnel pop operation after the validation.
- Reconfigure the dpdk port with rx checksum offload only if new configuration
is different than current one.

v2
- Set Rx checksum enabled by default.
- Modified commit message, explaining the tradeoff with tx checksum offloading.
- Use dpdk mbuf checksum offload flags  instead of defining new metadata field
in OVS dp_packet.
- validate udp checksum mbuf flag only if the checksum present in the packet.
- Doc update with Rx checksum offloading feature.
---
---
 Documentation/howto/dpdk.rst | 25 +++
 lib/dp-packet.h  | 29 +++
 lib/netdev-dpdk.c| 47 
 lib/netdev-native-tnl.c  | 35 +++--
 lib/netdev.c |  4 
 vswitchd/vswitch.xml | 14 +
 6 files changed, 139 insertions(+), 15 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index f55ae3b..115861c 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -273,6 +273,31 @@ largest frame size supported by Fortville NIC using the 
DPDK i40e driver, but
 larger frames and other DPDK NIC drivers may be supported. These cases are
 common for use cases involving East-West traffic only.
 
+Rx Checksum Offload
+---
+
+By default, DPDK physical ports are enabled with Rx checksum offload. Rx
+checksum offload can be configured on a DPDK physical port either when adding
+or at run time.
+
+To disable Rx checksum offload when adding a DPDK port dpdk0::
+
+$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
+  options:rx-checksum-offload=false
+
+Similarly to disable the Rx checksum offloading on a existing DPDK port dpdk0::
+
+$ ovs-vsctl set Interface dpdk0 type=dpdk options:rx-checksum-offload=false
+
+Rx checksum offload can offer performance improvement only for tunneling
+traffic in OVS-DPDK because the checksum validation of tunnel packets is
+offloaded to the NIC. Also enabling Rx checksum may slightly reduce the

[ovs-dev] [PATCH] netdev-dpdk: Enable Rx checksum offloading feature on DPDK physical ports.

[Sugesh Chandran]

Add Rx checksum offloading feature support on DPDK physical ports. By default,
the Rx checksum offloading is enabled if NIC supports. However,
the checksum offloading can be turned OFF either while adding a new DPDK
physical port to OVS or at runtime.

The rx checksum offloading can be turned off by setting the parameter to
'false'. For eg: To disable the rx checksum offloading when adding a port,

 'ovs-vsctl add-port br0 dpdk0 -- \
  set Interface dpdk0 type=dpdk options:rx-checksum-offload=false'

OR (to disable at run time after port is being added to OVS)

'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=false'

Similarly to turn ON rx checksum offloading at run time,
'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=true'

The Tx checksum offloading support is not implemented due to the following
reasons.

1) Checksum offloading and vectorization are mutually exclusive in DPDK poll
mode driver. Vector packet processing is turned OFF when checksum offloading
is enabled which causes significant performance drop at Tx side.

2) Normally, OVS generates checksum for tunnel packets in software at the
'tunnel push' operation, where the tunnel headers are created. However
enabling Tx checksum offloading involves,

*) Mark every packets for tx checksum offloading at 'tunnel_push' and
recirculate.
*) At the time of xmit, validate the same flag and instruct the NIC to do the
checksum calculation.  In case NIC doesnt support Tx checksum offloading,
the checksum calculation has to be done in software before sending out the
packets.

No significant performance improvement noticed with Tx checksum offloading
due to the e overhead of additional validations + non vector packet processing.
In some test scenarios, it introduces performance drop too.

Rx checksum offloading still offers 8-9% of improvement on VxLAN tunneling
decapsulation even though the SSE vector Rx function is disabled in DPDK poll
mode driver.

Signed-off-by: Sugesh Chandran 
Acked-by: Jesse Gross 

---
v8
- Update error log to clearly mention when the checksum offload is unsupported.
- Rebase to OVS latest master.

v7
- Update documentation with details of performance impact of having DPDK
vectorization in disabled state.
- Merge to latest OVS master.

v6
- Avoid unnecessary reconfiguration of DPDK ports when Rx checksum offload
support is unavailable.
- Limit the 'Rx checksum offload is unsupported' message in logging.
- Merge to latest OVS for DPDK 16.11 support. The DPDK checksum flags that used
- in the patch are only introduced in 16.11.

v5
- Reset the checksum flag in common tunnel pop function than in
'udp_extract_tnl_md' function.

v4
- Unconditonally clear off the checksum flag one time in pop operation than
doing separately in IP and UDP layers.

v3
- Reset the checksum offload flags in tunnel pop operation after the validation.
- Reconfigure the dpdk port with rx checksum offload only if new configuration
is different than current one.

v2
- Set Rx checksum enabled by default.
- Modified commit message, explaining the tradeoff with tx checksum offloading.
- Use dpdk mbuf checksum offload flags  instead of defining new metadata field
in OVS dp_packet.
- validate udp checksum mbuf flag only if the checksum present in the packet.
- Doc update with Rx checksum offloading feature.
---
---
 Documentation/howto/dpdk.rst | 25 +++
 lib/dp-packet.h  | 29 +++
 lib/netdev-dpdk.c| 47 
 lib/netdev-native-tnl.c  | 35 +++--
 lib/netdev.c |  4 
 vswitchd/vswitch.xml | 14 +
 6 files changed, 139 insertions(+), 15 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index f55ae3b..115861c 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -273,6 +273,31 @@ largest frame size supported by Fortville NIC using the 
DPDK i40e driver, but
 larger frames and other DPDK NIC drivers may be supported. These cases are
 common for use cases involving East-West traffic only.
 
+Rx Checksum Offload
+---
+
+By default, DPDK physical ports are enabled with Rx checksum offload. Rx
+checksum offload can be configured on a DPDK physical port either when adding
+or at run time.
+
+To disable Rx checksum offload when adding a DPDK port dpdk0::
+
+$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
+  options:rx-checksum-offload=false
+
+Similarly to disable the Rx checksum offloading on a existing DPDK port dpdk0::
+
+$ ovs-vsctl set Interface dpdk0 type=dpdk options:rx-checksum-offload=false
+
+Rx checksum offload can offer performance improvement only for tunneling
+traffic in OVS-DPDK because the checksum validation of tunnel packets is
+offloaded to the NIC. Also enabling Rx checksum may slightly reduce the

[ovs-dev] Dear Accredited Beneficiary,

[UNITED BANK FOR AFRICA]

UNITED BANK FOR AFRICA
UBA HOUSE, 57 MARINA LAGOS,
23th DECEMBER 2016,

Dear Accredited Beneficiary,

We believe this notification meets you in a very good present state of
mind and health. This communication serves to bring to your kindest
knowledge on the unilateral resolution and Memorandum of Understanding
signed with the World Bank Authority and the International Monetary
Agencies.
The resolution was basically on the fight against internet fraud,
corruption among some bank and government officials, and most
especially issues of Transfer Supporting Approval; that has been
delaying initiating prompt transfer of fund in West Africa countries
and United Kingdom.
In view of this; series of investigation was been carried out in some
of the reported banks and security companies in West Africa and their
affiliate centers in Europe, Asia and United Kingdom. On going through
this process several outstanding funds such as CONTRACT/INHERITANCE
FUNDS, COMPENSATIONS AND WINNING PAYMENTS was recovered of which yours
is among, after a detailed review of your file.
I am by this authority, informing you that a first part payment of
$800,000.00 USD and additional compensation payment of $50,000.00 USD
from government immunity funds, making a total of $850,000.00 USD has
been lawfully approved to be paid to you.
Kindly confirm receipt of this email on time, and provide us with your
information as stated below for recognition and processing of this
payment to you:
1) Your Names and residential Address,
2) Cell Phone Contact Number,
3) Present Occupation/Position and any copy of your official
identification (if any). Disabled/Retired;

Congratulations in advance!
Yours Faithfully,
Mrs.Carolyn Lande
( Senior Customer Care Director United Bank For Africa)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] doc: Correct type of highlighting

[Stephen Finucane]

Some recent changes marked code as Powershell when in fact it was DOS or
bash shell. This incorrect highlighting actually breaks the local build
(where warnings are treated as errors) as pygments is unable to lex all
the code as PowerShell. Fix these types.

Signed-off-by: Stephen Finucane 
Fixes: b8d24cc8a ("doc: Misc Windows doc formatting fixes")
---
 Documentation/intro/install/windows.rst | 290 
 1 file changed, 148 insertions(+), 142 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 1ba9b63..23a5a9b 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -105,9 +105,10 @@ The following explains the steps in some detail.
 .. note::
 
Commands prefixed by ``$`` must be run in the Bash shell provided by MinGW.
-   Open vSwitch commands, such as ``ovs-dpctl`` are shown running under
-   PowerShell (``>`` prefix) but will also run under Bash. The remainder,
-   prefixed by ``>``, are PowerShell commands and must be run in PowerShell.
+   Open vSwitch commands, such as ``ovs-dpctl`` are shown running under the DOS
+   shell (``cmd.exe``), as indicated by the ``>`` prefix, but will also run
+   under Bash. The remainder, prefixed by ``>``, are PowerShell commands and
+   must be run in PowerShell.
 
 Install Requirements
 
@@ -132,7 +133,7 @@ you pulled the sources directly from an Open vSwitch Git 
tree or got a
 Git tree snapshot, then run boot.sh in the top source directory to build
 the "configure" script:
 
-.. code-block:: bash
+.. code-block:: console
 
$ ./boot.sh
 
@@ -145,7 +146,7 @@ Configure the package by running the configure script.  You 
should provide some
 configure options to choose the right compiler, linker, libraries, Open vSwitch
 component installation directories, etc. For example:
 
-.. code-block:: bash
+.. code-block:: console
 
$ ./configure CC=./build-aux/cccl LD="$(which link)" \
LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -161,7 +162,7 @@ component installation directories, etc. For example:
 
 To configure with SSL support, add the requisite additional options:
 
-.. code-block:: bash
+.. code-block:: console
 
$ ./configure CC=./build-aux/cccl LD="`which link`"  \
LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -173,7 +174,7 @@ To configure with SSL support, add the requisite additional 
options:
 
 Finally, to the kernel module also:
 
-.. code-block:: bash
+.. code-block:: console
 
$ ./configure CC=./build-aux/cccl LD="`which link`" \
LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -203,7 +204,7 @@ building on Linux, FreeBSD, or NetBSD.
 
 #. Run make for the ported executables in the top source directory, e.g.:
 
-   .. code-block:: bash
+   .. code-block:: console
 
   $ make
 
@@ -223,19 +224,19 @@ building on Linux, FreeBSD, or NetBSD.
 
 #. To run all the unit tests in Open vSwitch, one at a time:
 
-   .. code-block:: bash
+   .. code-block:: console
 
   $ make check
 
To run all the unit tests in Open vSwitch, up to 8 in parallel:
 
-   .. code-block:: bash
+   .. code-block:: console
 
   $ make check TESTSUITEFLAGS="-j8"
 
 #. To install all the compiled executables on the local machine, run:
 
-   .. code-block:: bash
+   .. code-block:: console
 
   $ make install
 
@@ -268,11 +269,11 @@ Now run ``./uninstall.cmd`` to remove the old extension. 
Once complete, run
 turn on ``TESTSIGNING`` boot option or 'Disable Driver Signature
 Enforcement' during boot.  The following commands can be used:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
-   PS > bcdedit /set TESTSIGNING ON
-   PS > bcdedit /set nointegritychecks ON
+   > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
+   > bcdedit /set TESTSIGNING ON
+   > bcdedit /set nointegritychecks ON
 
 .. note::
 
@@ -286,7 +287,7 @@ to work (covered later).
 The command to create a new switch named 'OVS-Extended-Switch' using a physical
 NIC named 'Ethernet 1' is:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1"
 
@@ -299,7 +300,7 @@ In the properties of any switch, you should should now see 
"Open vSwitch
 Extension" under 'Extensions'.  Click the check box to enable the extension.
 An alternative way to do the same is to run the following command:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch
 
@@ -322,18 +323,18 @@ database, ovsdb-server. Each machine on which Open 
vSwitch is installed should
 run its own copy of ovsdb-server. Before ovsdb-server itself can be started,
 configure a database that it can use:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovsdb-tool create 

[ovs-dev] [PATCH 5/6] ovn: avoid snat recirc only on gateway routers

[Mickey Spiegel]

Currently, for performance reasons on gateway routers, ct_snat
that does not specify an IP address does not immediately trigger
recirculation.  On gateway routers, ct_snat that does not specify
an IP address happens in the UNSNAT pipeline stage, which is
followed by the DNAT pipeline stage that triggers recirculation
for all packets.  This DNAT pipeline stage recirculation takes
care of the recirculation needs of UNSNAT as well as other cases
such as UNDNAT.

On distributed routers, UNDNAT is handled in the egress pipeline
stage, separately from DNAT in the ingress pipeline stages.  The
DNAT pipeline stage only triggers recirculation for some packets.
Due to this difference in design, UNSNAT needs to trigger its own
recirculation.

This patch restricts the logic that avoids recirculation for
ct_snat, so that it only applies to datapaths representing
gateway routers.

Signed-off-by: Mickey Spiegel 
---
 include/ovn/actions.h  |  3 +++
 ovn/controller/lflow.c | 10 ++
 ovn/lib/actions.c  | 15 +--
 tests/ovn.at   |  2 +-
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 0bf6145..0451c08 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -417,6 +417,9 @@ struct ovnact_encode_params {
 /* 'true' if the flow is for a switch. */
 bool is_switch;
 
+/* 'true' if the flow is for a gateway router. */
+bool is_gateway_router;
+
 /* A map from a port name to its connection tracking zone. */
 const struct simap *ct_zones;
 
diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index 0384c8d..e94d869 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -125,6 +125,15 @@ is_switch(const struct sbrec_datapath_binding *ldp)
 
 }
 
+static bool
+is_gateway_router(const struct sbrec_datapath_binding *ldp,
+  const struct hmap *local_datapaths)
+{
+struct local_datapath *ld =
+get_local_datapath(local_datapaths, ldp->tunnel_key);
+return ld ? ld->has_local_l3gateway : false;
+}
+
 /* Adds the logical flows from the Logical_Flow table to flow tables. */
 static void
 add_logical_flows(struct controller_ctx *ctx, const struct lport_index *lports,
@@ -238,6 +247,7 @@ consider_logical_flow(const struct lport_index *lports,
 .lookup_port = lookup_port_cb,
 .aux = ,
 .is_switch = is_switch(ldp),
+.is_gateway_router = is_gateway_router(ldp, local_datapaths),
 .ct_zones = ct_zones,
 .group_table = group_table,
 
diff --git a/ovn/lib/actions.c b/ovn/lib/actions.c
index 686ecc5..3da3dbe 100644
--- a/ovn/lib/actions.c
+++ b/ovn/lib/actions.c
@@ -788,12 +788,15 @@ encode_ct_nat(const struct ovnact_ct_nat *cn,
 ct = ofpacts->header;
 if (cn->ip) {
 ct->flags |= NX_CT_F_COMMIT;
-} else if (snat) {
-/* XXX: For performance reasons, we try to prevent additional
- * recirculations.  So far, ct_snat which is used in a gateway router
- * does not need a recirculation. ct_snat(IP) does need a
- * recirculation.  Should we consider a method to let the actions
- * specify whether an action needs recirculation if there more use
+} else if (snat && ep->is_gateway_router) {
+/* For performance reasons, we try to prevent additional
+ * recirculations.  ct_snat which is used in a gateway router
+ * does not need a recirculation.  ct_snat(IP) does need a
+ * recirculation.  ct_snat in a distributed router needs
+ * recirculation regardless of whether an IP address is
+ * specified.
+ * XXX Should we consider a method to let the actions specify
+ * whether an action needs recirculation if there are more use
  * cases?. */
 ct->recirc_table = NX_CT_RECIRC_NONE;
 }
diff --git a/tests/ovn.at b/tests/ovn.at
index 801b447..f64b335 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -852,7 +852,7 @@ ct_dnat();
 
 # ct_snat
 ct_snat;
-encodes as ct(zone=NXM_NX_REG12[0..15],nat)
+encodes as ct(table=27,zone=NXM_NX_REG12[0..15],nat)
 has prereqs ip
 ct_snat(192.168.1.2);
 encodes as 
ct(commit,table=27,zone=NXM_NX_REG12[0..15],nat(src=192.168.1.2))
-- 
1.9.1

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

[ovs-dev] [PATCH 4/6] ovn: move load balancing flows after NAT flows

[Mickey Spiegel]

This will make it easy for distributed NAT to reuse some of the
existing code for NAT flows, while leaving load balancing and defrag
as functionality specific to gateway routers.  There is no intent to
change any functionality in this patch.

Signed-off-by: Mickey Spiegel 
---
 ovn/northd/ovn-northd.c | 140 
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 6779d46..a333d1c 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -4068,76 +4068,6 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 const char *lb_force_snat_ip = get_force_snat_ip(od, "lb",
  _ip);
 
-/* A set to hold all ips that need defragmentation and tracking. */
-struct sset all_ips = SSET_INITIALIZER(_ips);
-
-for (int i = 0; i < od->nbr->n_load_balancer; i++) {
-struct nbrec_load_balancer *lb = od->nbr->load_balancer[i];
-struct smap *vips = >vips;
-struct smap_node *node;
-
-SMAP_FOR_EACH (node, vips) {
-uint16_t port = 0;
-
-/* node->key contains IP:port or just IP. */
-char *ip_address = NULL;
-ip_address_and_port_from_lb_key(node->key, _address, );
-if (!ip_address) {
-continue;
-}
-
-if (!sset_contains(_ips, ip_address)) {
-sset_add(_ips, ip_address);
-}
-
-/* Higher priority rules are added for load-balancing in DNAT
- * table.  For every match (on a VIP[:port]), we add two flows
- * via add_router_lb_flow().  One flow is for specific matching
- * on ct.new with an action of "ct_lb($targets);".  The other
- * flow is for ct.est with an action of "ct_dnat;". */
-ds_clear();
-ds_put_format(, "ct_lb(%s);", node->value);
-
-ds_clear();
-ds_put_format(, "ip && ip4.dst == %s",
-  ip_address);
-free(ip_address);
-
-if (port) {
-if (lb->protocol && !strcmp(lb->protocol, "udp")) {
-ds_put_format(, " && udp && udp.dst == %d",
-  port);
-} else {
-ds_put_format(, " && tcp && tcp.dst == %d",
-  port);
-}
-add_router_lb_flow(lflows, od, , , 120,
-   lb_force_snat_ip);
-} else {
-add_router_lb_flow(lflows, od, , , 110,
-   lb_force_snat_ip);
-}
-}
-}
-
-/* If there are any load balancing rules, we should send the
- * packet to conntrack for defragmentation and tracking.  This helps
- * with two things.
- *
- * 1. With tracking, we can send only new connections to pick a
- *DNAT ip address from a group.
- * 2. If there are L4 ports in load balancing rules, we need the
- *defragmentation to match on L4 ports. */
-const char *ip_address;
-SSET_FOR_EACH(ip_address, _ips) {
-ds_clear();
-ds_put_format(, "ip && ip4.dst == %s", ip_address);
-ovn_lflow_add(lflows, od, S_ROUTER_IN_DEFRAG,
-  100, ds_cstr(), "ct_next;");
-}
-
-sset_destroy(_ips);
-
 for (int i = 0; i < od->nbr->n_nat; i++) {
 const struct nbrec_nat *nat;
 
@@ -4292,6 +4222,76 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 * routing in the openflow pipeline. */
 ovn_lflow_add(lflows, od, S_ROUTER_IN_DNAT, 50,
   "ip", "flags.loopback = 1; ct_dnat;");
+
+/* A set to hold all ips that need defragmentation and tracking. */
+struct sset all_ips = SSET_INITIALIZER(_ips);
+
+for (int i = 0; i < od->nbr->n_load_balancer; i++) {
+struct nbrec_load_balancer *lb = od->nbr->load_balancer[i];
+struct smap *vips = >vips;
+struct smap_node *node;
+
+SMAP_FOR_EACH (node, vips) {
+uint16_t port = 0;
+
+/* node->key contains IP:port or just IP. */
+char *ip_address = NULL;
+ip_address_and_port_from_lb_key(node->key, _address, );
+if (!ip_address) {
+continue;
+}
+
+if (!sset_contains(_ips, ip_address)) {
+sset_add(_ips, ip_address);
+}
+
+/* Higher priority rules are added for load-balancing in DNAT
+ 

[ovs-dev] [PATCH 2/6] ovn: Introduce "chassisredirect" port binding

[Mickey Spiegel]

Currently OVN handles all logical router ports in a distributed manner,
creating instances on each chassis.  The logical router ingress and
egress pipelines are traversed locally on the source chassis.

In order to support advanced features such as one-to-many NAT (aka IP
masquerading), where multiple private IP addresses spread across
multiple chassis are mapped to one public IP address, it will be
necessary to handle some of the logical router processing on a specific
chassis in a centralized manner.

The goal of this patch is to develop abstractions that allow for a
subset of router gateway traffic to be handled in a centralized manner
(e.g. one-to-many NAT traffic), while allowing for other subsets of
router gateway traffic to be handled in a distributed manner (e.g.
floating IP traffic).

This patch introduces a new type of SB port_binding called
"chassisredirect".  A "chassisredirect" port represents a particular
instance, bound to a specific chassis, of an otherwise distributed
port.  The ovn-controller on that chassis populates the "chassis"
column for this record as an indication for other ovn-controllers of
its physical location.  Other ovn-controllers do not treat this port
as a local port.

A "chassisredirect" port should never be used as an "inport".  When an
ingress pipeline sets the "outport", it may set the value to a logical
port of type "chassisredirect".  This will cause the packet to be
directed to a specific chassis to carry out the egress logical router
pipeline, in the same way that a logical switch forwards egress traffic
to a VIF port residing on a specific chassis.  At the beginning of the
egress pipeline, the "outport" will be reset to the value of the
distributed port.

For outbound traffic to be handled in a centralized manner, the
"outport" should be set to the "chassisredirect" port representing
centralized gateway functionality in the otherwise distributed router.
For outbound traffic to be handled in a distributed manner, locally on
the source chassis, the "outport" should be set to the existing "patch"
port representing distributed gateway functionality.

Inbound traffic will be directed to the appropriate chassis by
restricting source MAC address usage and ARP responses to that chassis,
or by running dynamic routing protocols.

Note that "chassisredirect" ports have no associated IP or MAC addresses.
Any pipeline stages that depend on port specific IP or MAC addresses
should be carried out in the context of the distributed port.

Although the abstraction represented by the "chassisredirect" port
binding is generalized, in this patch the "chassisredirect" port binding
is only created for NB logical router ports that specify the new
"redirect-chassis" option.  There is no explicit notion of a
"chassisredirect" port in the NB database.  The expectation is when
capabilities are implemented that take advantage of "chassisredirect"
ports (e.g. NAT), the addition of flows specifying a "chassisredirect"
port as the outport will also be triggered by the presence of the
"redirect-chassis" option.

Signed-off-by: Mickey Spiegel 
---
 ovn/controller/binding.c|   8 ++
 ovn/controller/ovn-controller.c |   4 +
 ovn/controller/physical.c   |  63 +
 ovn/northd/ovn-northd.8.xml |  75 ++-
 ovn/northd/ovn-northd.c | 195 ++--
 ovn/ovn-nb.ovsschema|   9 +-
 ovn/ovn-nb.xml  |  30 +
 ovn/ovn-sb.xml  |  35 +
 tests/ovn.at| 275 
 9 files changed, 682 insertions(+), 12 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 2f24e9d..25592c2 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -355,6 +355,14 @@ consider_local_datapath(struct controller_ctx *ctx,
 add_local_datapath(ldatapaths, lports, binding_rec->datapath,
false, local_datapaths);
 }
+} else if (!strcmp(binding_rec->type, "chassisredirect")) {
+const char *chassis_id = smap_get(_rec->options,
+  "redirect-chassis");
+our_chassis = chassis_id && !strcmp(chassis_id, chassis_rec->name);
+if (our_chassis) {
+add_local_datapath(ldatapaths, lports, binding_rec->datapath,
+   false, local_datapaths);
+}
 } else if (!strcmp(binding_rec->type, "l3gateway")) {
 const char *chassis_id = smap_get(_rec->options,
   "l3gateway-chassis");
diff --git a/ovn/controller/ovn-controller.c b/ovn/controller/ovn-controller.c
index 5bddcf3..131c900 100644
--- a/ovn/controller/ovn-controller.c
+++ b/ovn/controller/ovn-controller.c
@@ -155,6 +155,10 @@ update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
 sbrec_port_binding_add_clause_options(, OVSDB_F_INCLUDES, );
 const struct smap l3 = 

[ovs-dev] [PATCH 3/6] ovn: add egress loopback capability

[Mickey Spiegel]

This patch adds the capability to force loopback at the end of the
egress pipeline.  A new flags.force_egress_loopback symbol is defined,
along with corresponding flags bits.  When flags.force_egress_loopback
is set, at OFTABLE_LOG_TO_PHY, instead of the packet being sent out to
the peer patch port or out the outport, the packet is forced back to
the beginning of the ingress pipeline with inport = outport.  All
other registers are cleared, as if the packet just arrived on that
inport.

This capability is needed in order to implement some of the east/west
distributed NAT flows.

Note: The existing flags.loopback allows a packet to go from the end
of the ingress pipeline to the beginning of the egress pipeline with
outport = inport, which is different.

Initially, there are no tests incorporated in this patch.  This
functionality is tested in a subsequent distributed NAT flows patch.
Tests specific to egress loopback may be added once the capability
to inject a packet with one of the flags bits set is added.

Signed-off-by: Mickey Spiegel 
---
 ovn/controller/physical.c   | 38 ++
 ovn/lib/logical-fields.c|  8 
 ovn/lib/logical-fields.h| 14 ++
 ovn/northd/ovn-northd.8.xml |  4 +++-
 ovn/northd/ovn-northd.c |  2 ++
 ovn/ovn-sb.xml  |  2 +-
 6 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 3ea1290..cba1c0e 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -183,7 +183,7 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 }
 
 static void
-put_local_common_flows(uint32_t dp_key, uint32_t port_key,
+put_local_common_flows(uint32_t dp_key, uint32_t port_key, ofp_port_t ofport,
bool nested_container, const struct zone_ids *zone_ids,
struct ofpbuf *ofpacts_p, struct hmap *flow_table)
 {
@@ -258,6 +258,36 @@ put_local_common_flows(uint32_t dp_key, uint32_t port_key,
 put_resubmit(OFTABLE_LOG_TO_PHY, ofpacts_p);
 put_stack(MFF_IN_PORT, ofpact_put_STACK_POP(ofpacts_p));
 ofctrl_add_flow(flow_table, OFTABLE_SAVE_INPORT, 100, , ofpacts_p);
+
+/* Table 65, Priority 150.
+ * ===
+ *
+ * Send packets with MLF_FORCE_EGRESS_LOOPBACK flag back to the
+ * ingress pipeline with inport = outport. */
+
+match_init_catchall();
+ofpbuf_clear(ofpacts_p);
+match_set_metadata(, htonll(dp_key));
+match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
+match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_FORCE_EGRESS_LOOPBACK, MLF_FORCE_EGRESS_LOOPBACK);
+
+size_t clone_ofs = ofpacts_p->size;
+struct ofpact_nest *clone = ofpact_put_CLONE(ofpacts_p);
+put_load(ofport, MFF_IN_PORT, 0, 16, ofpacts_p);
+put_load(port_key, MFF_LOG_INPORT, 0, 32, ofpacts_p);
+put_load(0, MFF_LOG_OUTPORT, 0, 32, ofpacts_p);
+put_load(MLF_EGRESS_LOOPBACK_OCCURRED, MFF_LOG_FLAGS, 0, 32, ofpacts_p);
+for (int i = 0; i < MFF_N_LOG_REGS; i++) {
+put_load(0, MFF_LOG_REG0 + i, 0, 32, ofpacts_p);
+}
+put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, ofpacts_p);
+clone = ofpbuf_at_assert(ofpacts_p, clone_ofs, sizeof *clone);
+ofpacts_p->header = clone;
+ofpact_finish_CLONE(ofpacts_p, );
+
+ofctrl_add_flow(flow_table, OFTABLE_LOG_TO_PHY, 150,
+, ofpacts_p);
 }
 
 static void
@@ -320,7 +350,7 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
 }
 
 struct zone_ids binding_zones = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, false, _zones,
+put_local_common_flows(dp_key, port_key, 0, false, _zones,
ofpacts_p, flow_table);
 
 match_init_catchall();
@@ -489,8 +519,8 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
  */
 
 struct zone_ids zone_ids = get_zone_ids(binding, ct_zones);
-put_local_common_flows(dp_key, port_key, nested_container, _ids,
-   ofpacts_p, flow_table);
+put_local_common_flows(dp_key, port_key, ofport, nested_container,
+   _ids, ofpacts_p, flow_table);
 
 /* Table 0, Priority 150 and 100.
  * ==
diff --git a/ovn/lib/logical-fields.c b/ovn/lib/logical-fields.c
index fa134d6..c056e41 100644
--- a/ovn/lib/logical-fields.c
+++ b/ovn/lib/logical-fields.c
@@ -96,6 +96,14 @@ ovn_init_symtab(struct shash *symtab)
  MLF_FORCE_SNAT_FOR_LB_BIT);
 expr_symtab_add_subfield(symtab, "flags.force_snat_for_lb", NULL,
  flags_str);
+snprintf(flags_str, sizeof flags_str, "flags[%d]",
+ MLF_FORCE_EGRESS_LOOPBACK_BIT);
+expr_symtab_add_subfield(symtab, "flags.force_egress_loopback", NULL,
+ flags_str);
+

[ovs-dev] [PATCH 1/6] ovn: add is_chassis_resident match expression component

[Mickey Spiegel]

This patch introduces a new match expression component
is_chassis_resident().  Unlike match expression comparisons,
is_chassis_resident is not pushed down to OpenFlow.  It is a
conditional that is evaluated in the controller during expr_simplify(),
when it is replaced by a boolean expression.  The is_chassis_resident
conditional evaluates to "true" when the specified string identifies a
port name that is resident on this controller chassis, i.e., the
corresponding southbound database Port_Binding has a chassis column
that matches this chassis.  Otherwise it evaluates to "false".

This allows higher level features to specify flows that are only
installed on some chassis rather than on all chassis with the
corresponding datapath.

Suggested-by: Ben Pfaff 
Signed-off-by: Mickey Spiegel 
---
 include/ovn/expr.h  |  22 +-
 ovn/controller/lflow.c  |  39 --
 ovn/controller/lflow.h  |   5 +-
 ovn/controller/ovn-controller.c |   5 +-
 ovn/lib/expr.c  | 155 ++--
 ovn/utilities/ovn-trace.c   |  21 +-
 tests/ovn.at|  14 
 tests/test-ovn.c|  15 +++-
 8 files changed, 260 insertions(+), 16 deletions(-)

diff --git a/include/ovn/expr.h b/include/ovn/expr.h
index 371ba20..d3749fa 100644
--- a/include/ovn/expr.h
+++ b/include/ovn/expr.h
@@ -292,6 +292,15 @@ enum expr_type {
 EXPR_T_AND, /* Logical AND of 2 or more subexpressions. */
 EXPR_T_OR,  /* Logical OR of 2 or more subexpressions. */
 EXPR_T_BOOLEAN, /* True or false constant. */
+EXPR_T_CONDITION,   /* Conditional to be evaluated in the
+ * controller during expr_simplify(),
+ * prior to constructing OpenFlow matches. */
+};
+
+/* Expression condition type. */
+enum expr_cond_type {
+EXPR_COND_CHASSIS_RESIDENT, /* Check if specified logical port name is
+ * resident on the controller chassis. */
 };
 
 /* Relational operator. */
@@ -349,6 +358,14 @@ struct expr {
 
 /* EXPR_T_BOOLEAN. */
 bool boolean;
+
+/* EXPR_T_CONDITION. */
+struct {
+enum expr_cond_type type;
+bool not;
+/* XXX Should arguments for conditions be generic? */
+char *string;
+} cond;
 };
 };
 
@@ -375,7 +392,10 @@ void expr_destroy(struct expr *);
 
 struct expr *expr_annotate(struct expr *, const struct shash *symtab,
char **errorp);
-struct expr *expr_simplify(struct expr *);
+struct expr *expr_simplify(struct expr *,
+   bool (*is_chassis_resident)(const void *c_aux,
+   const char *port_name),
+   const void *c_aux);
 struct expr *expr_normalize(struct expr *);
 
 bool expr_honors_invariants(const struct expr *);
diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index d913998..0384c8d 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -64,12 +64,18 @@ struct lookup_port_aux {
 const struct sbrec_datapath_binding *dp;
 };
 
+struct condition_aux {
+const struct lport_index *lports;
+const struct sbrec_chassis *chassis;
+};
+
 static void consider_logical_flow(const struct lport_index *lports,
   const struct mcgroup_index *mcgroups,
   const struct sbrec_logical_flow *lflow,
   const struct hmap *local_datapaths,
   struct group_table *group_table,
   const struct simap *ct_zones,
+  const struct sbrec_chassis *chassis,
   struct hmap *dhcp_opts_p,
   struct hmap *dhcpv6_opts_p,
   uint32_t *conj_id_ofs_p,
@@ -99,6 +105,20 @@ lookup_port_cb(const void *aux_, const char *port_name, 
unsigned int *portp)
 }
 
 static bool
+is_chassis_resident_cb(const void *c_aux_, const char *port_name)
+{
+const struct condition_aux *c_aux = c_aux_;
+
+const struct sbrec_port_binding *pb
+= lport_lookup_by_name(c_aux->lports, port_name);
+if (pb && pb->chassis && pb->chassis == c_aux->chassis) {
+return true;
+}
+
+return false;
+}
+
+static bool
 is_switch(const struct sbrec_datapath_binding *ldp)
 {
 return smap_get(>external_ids, "logical-switch") != NULL;
@@ -112,6 +132,7 @@ add_logical_flows(struct controller_ctx *ctx, const struct 
lport_index *lports,
   const struct hmap *local_datapaths,
   struct group_table *group_table,
   const struct simap *ct_zones,
+  const struct sbrec_chassis *chassis,
   struct 

[ovs-dev] [PATCH 0/6] ovn: add distributed NAT capability

[Mickey Spiegel]

Currently OVN supports NAT functionality by connecting each distributed
logical router to a centralized "l3gateway" router that resides on a
single chassis.  NAT is only carried out in the "l3gateway" router.

This patch set introduces NAT capability in the distributed logical
router itself, avoiding the need to pass through a transit logical
switch and a second logical router, and in many cases avoiding the need
to pass through a centralized chassis.

NAT functionality is associated with the logical router gateway port.
In order to support one-to-many SNAT (aka IP masquerading), where
multiple private IP addresses spread across multiple chassis are mapped
to a single public IP address, it will be necessary to handle some of
the logical router processing on a specific chassis in a centralized
manner.  Some NAT flows are handled in a distributed manner on all
chassis (following the local "patch" port as is normally done for
distributed logical routers), while other NAT flows are handled on a
centralized "redirect-chassis".

Possible future work items (hopefully not required for this patch set
to be accepted) include:
1. The NAT flows patch lifts the restriction that conntrack zones are
   only assigned to datapaths for gateway routers.  Given recent
   changes to ovn-controller, a hypervisor only sees the datapaths
   for which there is a port resident on this chassis, or datapaths
   reachable from ports resident on this chassis.  Is that good
   enough?  Or should conntrack zone assignment for datapaths be
   restricted further, perhaps only to logical router datapaths?
2. The current automated test for NAT flows is single node, so it does
   not cover the distributed functionality.  Full coverage requires a
   multi-node test with conntrack NAT capability, either in the kernel
   or userspace.  Is this possible?
   Multi-node tests have been added for the chassisdirect patch,
   testing non-NAT aspects of the distributed router gateway port.
3. Consider how to generalize distributed versus centralized handling
   of non-NAT traffic being output on the distributed gateway port.
   If MAC learning is used in the upstream network, then the
   distributed gateway port’s MAC address must be restricted to the
   redirect-chassis by using the chassisredirect port.  In the
   presence of dynamic protocols such as BGP EVPN, non-NAT traffic
   could be handled in a distributed manner.
4. Gratuitous ARP for NAT addresses needs to be updated for
   distributed NAT.
5. Add load balancing on the redirect chassis of an otherwise
   distributed logical router.

RFC v4 -> PATCH v1
Added egress loopback capability
Added east/west NAT tests to system-ovn.at (make check-kernel)
Added REGBIT_NAT_REDIRECT flows to IN_IP_ROUTING and IN_ARP_RESOLVE,
resolving remaining issues with east/west NAT

RFC v3 -> RFC v4
Rebased to pick up recent changes to ovn-controller, including a fix
to the localnet issue where VIFs had to be added on a chassis in order
to cause the localnet port to be instantiated.
The chassisredirect port logic was rewritten to avoid creating an
ofport.  Besides streamlining the code significantly, this fixed the
problem when the distributed port name was longer than 12 characters.
Restricted IPv6 ND replies for the router IP address to the redirect
chassis, similar to IPv4 ARP restrictions.
Added specific gateway redirect flows for unresolved ethernet
destination, so that ARP requests generated by the router are sent
through the redirect chassis regardless of NAT rules.
Relaxed checks in chassisredirect tests so that they are independent
of register assignments.
Renamed ovn-northd.c "l3gateway_port" to "l3dgw_port" in order to
avoid overlaps with gateway router terminology.

RFC v2 -> RFC v3
Reordered the first two patches.
Moved non-NAT specific flows from patch 5 to patch 2.
Added automated tests for is_chassis_resident (which is ready for
review) and chassisredirect patches.
Added flows to limit ICMP echo replies for router IPs on the gateway
interface, so that they are only generated on the redirect-chassis.

Mickey Spiegel (6):
  ovn: add is_chassis_resident match expression component
  ovn: Introduce "chassisredirect" port binding
  ovn: add egress loopback capability
  ovn: move load balancing flows after NAT flows
  ovn: avoid snat recirc only on gateway routers
  ovn: distributed NAT flows

 include/ovn/actions.h   |   3 +
 include/ovn/expr.h  |  22 +-
 ovn/controller/binding.c|   8 +
 ovn/controller/lflow.c  |  49 ++-
 ovn/controller/lflow.h  |   5 +-
 ovn/controller/ovn-controller.c |  15 +-
 ovn/controller/physical.c   | 101 +-
 ovn/lib/actions.c   |  15 +-
 ovn/lib/expr.c  | 155 -
 ovn/lib/logical-fields.c|   8 +
 ovn/lib/logical-fields.h|  14 +
 ovn/northd/ovn-northd.8.xml | 372 -
 ovn/northd/ovn-northd.c | 702 
 

Re: [ovs-dev] [PATCH v7] netdev-dpdk: Enable Rx checksum offloading feature on DPDK physical ports.

[Chandran, Sugesh]

Regards
_Sugesh


> >> >> > +rx_csum_ol_flag = (dev->hw_ol_features &
> >> >> > +NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
> >> >> > +
> >> >> > +if (rx_csum_ol_flag &&
> >> >> > +(info.rx_offload_capa & rx_chksm_offload_capa) !=
> >> >> > + rx_chksm_offload_capa) {
> >> >> > +VLOG_WARN_ONCE("Failed to enable Rx checksum offload on
> >> >> > + device
> >> >> %d",
> >> >> > +   dev->port_id);
> This is not clear error msg. In this case device does not support requested
> offload feature. So the msg should mention that.
[Sugesh] Ok, Will change the error log message stating device doesn’t support 
the feature.
> 
> >> >> > +dev->hw_ol_features &= ~NETDEV_RX_CHECKSUM_OFFLOAD;
> >> >> > +return;
> >> >> > +}
> >> >> > +netdev_request_reconfigure(>up);
> >> >> > +}
> >> >> > +
> >> >> I am not sure about need for netdev reconfigure here.
> >> > [Sugesh] Reconfigure is called here to enable/disable the checksum
> >> > at run time. Do you think the checksum will be updated on a user
> >> > request without having this call?
> >>
> >> I do not see need to reconfigure netdev here.
> > [Sugesh] Sorry Pravin, Looks like I am missing something here. Can you
> > please elaborate why you feel the reconfigure is not needed here?
> 
> I thought we can enable rx checksum offload synchronously, but the device
> API does not allow it, so I agree we have to reconfigure netdev here.
[Sugesh] Ok
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev