Re: [ovs-dev] (no subject)

2017-11-03 Thread Tom Crist
Hallo, Sie haben eine Spende von $ 4,800,000.00, ich habe die America Lotto
in Amerika gewonnen
Im Wert von $ 40 Millionen, und ich gebe einen Teil davon an fünf
glückliche Menschen und Wohltätigkeits-Häuser in Erinnerung an meine
verstorbene Frau, die an Krebs gestorben ist. Kontaktieren Sie mich für
weitere Details: tomcristloveaud...@gmail.com cheers tom crist
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK

2017-11-03 Thread Darrell Ball


From: Jan Scheurich 
Date: Friday, November 3, 2017 at 6:22 AM
To: Darrel Ball , Rohith Basavaraja 

Cc: "d...@openvswitch.org" 
Subject: RE: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK

Hi Darrel,

I have now been able to actually test the example pipelines I provided earlier. 
Turns out that the first one I sent was correct.

[Darrell] Sure, let us discuss the first example; let me know if you want to 
discuss the second example you gave as well.


Please note that it was not meant as realistic conntrack pipeline

Darrell] Again, I can agree your example is not realistic or recommended. No 
one would write rules like this.
  The rules would certainly be written properly so that the trusted 
direction (the one that does the commit) allows the first packet through;
  this is a fundamental principle of conntrack. There are an 
infinite number of ways to misuse conntrack rules and no one can prevent misuse.
  On a similar topic, another fundamental problem I saw with the 
original discussion (from Aug) is creating a conntrack pipeline that commits
  a connection in the untrusted direction. That is also not 
something we do or recommend others do. This ‘suboptimal design approach’ 
brought
  us to the question on when a packet gets labelled as ESTABLISHED. 
 Normally, the difference would not be noticed, since a connection would not be
  committed in the untrusted direction and hence EST would not be 
possible unless another rule correctly commits in the trusted direction.
  I’ll add more comments below.


but just to demonstrate the misalignment between userspace and kernel conntrack 
and the conflict of both with the documentation.

The following pipeline is now tested:

ovs-ofctl add-flow br0 "table=0,priority=10,in_port=1,icmp 
actions=ct(table=1,zone=5000)"
ovs-ofctl add-flow br0 "table=0,priority=10,in_port=1,arp actions=output:2"
ovs-ofctl add-flow br0 "table=0,priority=10,in_port=2 actions=output:1"
ovs-ofctl add-flow br0 
"table=1,priority=10,in_port=1,ct_state=-new+est-rel-inv+trk actions=output:2"
ovs-ofctl add-flow br0 "table=1,priority=10,in_port=1,ip,ct_state=+new+trk 
actions=ct(commit,zone=5000),goto_table:2"
ovs-ofctl add-flow br0 
"table=2,priority=10,in_port=1,ct_state=-new+est-rel-inv+trk actions=output:2"

The ct(commit) action in table 1 commits a new connection entry, but the 
subsequent match in table 2 proves that the ct_state of the packet is still not 
EST despite the commit.

>

[Darrell] I assumed you meant “lack of match in table 2” per your following 
test result.
   You use zoning in your rules without effect and you even split 
the pipeline with goto_table – we would not do this.
   Out of 6 rules, probably at least 4 of them are not what you 
want.
   I think there is a big disconnect here and I feel we are wasting 
time discussing such a contrived pipeline.

Here is a simplified set of rules that might be reasonably used for just icmp:

priority=1,action=drop
priority=10,arp,action=normal
table=0,priority=10,in_port=2,icmp,ct_state=-trk,action=ct(table=0)
table=0,priority=10,in_port=2,icmp,ct_state=+trk+est actions=output:1
table=0,priority=10,in_port=1,icmp actions=ct(commit,table=1)
table=1,priority=10,in_port=1,icmp,ct_state=+trk+est actions=output:2
table=1,priority=10,in_port=1,icmp,ct_state=+trk+new actions=output:2

<


This contradicts the statement in man ovs-fields: “est (0x02)  Part of an 
existing connection. Set to 1 if this is a committed connection.”

>
[Darrell]
No, it does not.
Same answer as earlier

[Darrell   Let me clear up some misconceptions, ct(commit ) is a prerequisite 
for EST being set for a later packet seen. A ‘packet’ (not a connection) that 
hits an
 existing conntrack entry is marked as established and that’s 
what the documentation says; the idea behind the ‘OVS conntrack EST state’ is 
to make
 the state intuitive.

“est (0x02)  Part of an existing connection. Set to 1 if this is a committed 
connection.”

ESTABLISHED is an attribute of a packet hitting an existing conntrack entry 
(“Part of an existing connection”), not the conntrack entry itself.
So, a packet that hits an ‘existing’ entry (which is a committed connection, of 
course) gets its state set to EST.
I agree this is subtle, because the reader has to know that EST is a state of 
the packet not the connection entry itself; the wording could have been better.
<


Consequently the userspace datapath drops the first ICMP packet:

root@ubuntu:~# ip netns exec ns1 ping -c1 192.168.10.20
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
--- 192.168.10.20 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@ubuntu:/opt/ovs# ovs-ofctl -Oopenflow13 dump-flows br0
cookie=0x0, duration=30.885s, table=0, n_packets=1, n_bytes=98, reset_counts 
priority=10,ic

[ovs-dev] Téléphone 01 76 24 30 81

2017-11-03 Thread B. LEBIENTRE
Le Magnétisme permet par simple imposition des mains de soulager en re- 
harmonisant les energies. 
Decouvrez les pouvoirs qui sont caches en vous !profitez de notre reduction 
exceptionnelle de 35 % 

 
Cette formation de Praticien en Magnetisme vise dans un premier temps, a faire 
prendre conscience a chaque participant de son potentiel energetique pour, par 
la suite, par le biais d exercices ludiques et de techniques simples, lui 
apprendre a l utiliser a bon escient et a l amplifier. Ce cursus est OUVERT A 
TOUS. Le Magnetisme est une therapie efficace, sans danger, facile a apprendre 
et a pratiquer, afin de pouvoir aider les autres a retrouver un bien-etre tant 
physique que psychologique. Pour en savoir plus :



 
Ce que vous apprendrez :
 
- L'être humain en medecine energetique- Vie et enseignements de quelques 
guerisseurs- Ressentir l energie et apprendre a la maitriser- Techniques du 
Magnétisme traditionnel- Techniques Quantiques- Autres Techniques Specifiques- 
Faire des soins en face-a-face et a distance- ethique et valeurs du 
magnetiseur- Comment commencer et developper son activite
 
Decouvrez le Magnetisme avec une formation a partir de 390eet profitez de notre 
reduction exceptionnelle de 35 % soit 255e au lieu de 390e
 
 
 
 
 

 

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


Re: [ovs-dev] [PATCH v2] dpctl: manage ret value when dumping CT entries.

2017-11-03 Thread Ben Pfaff
I applied this to master and added that tag.

Thanks,

Ben.

On Tue, Sep 26, 2017 at 09:45:16AM +, Fischetti, Antonio wrote:
> Actually I forgot to add in the commit message
> 
> Reviewed-by: Greg Rose 
> 
> Can this please be added later?
> 
> Thanks, Antonio
> 
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org 
> > [mailto:ovs-dev-boun...@openvswitch.org]
> > On Behalf Of antonio.fische...@intel.com
> > Sent: Tuesday, September 26, 2017 10:37 AM
> > To: d...@openvswitch.org
> > Subject: [ovs-dev] [PATCH v2] dpctl: manage ret value when dumping CT 
> > entries.
> > 
> > Manage error value returned by ct_dpif_dump_next.
> > 
> > Signed-off-by: Antonio Fischetti 
> > ---
> >  lib/dpctl.c | 27 ---
> >  1 file changed, 24 insertions(+), 3 deletions(-)
> > 
> > diff --git a/lib/dpctl.c b/lib/dpctl.c
> > index 8951d6e..d229c97 100644
> > --- a/lib/dpctl.c
> > +++ b/lib/dpctl.c
> > @@ -1286,7 +1286,7 @@ dpctl_dump_conntrack(int argc, const char *argv[],
> >  return error;
> >  }
> > 
> > -while (!ct_dpif_dump_next(dump, &cte)) {
> > +while (!(error = ct_dpif_dump_next(dump, &cte))) {
> >  struct ds s = DS_EMPTY_INITIALIZER;
> > 
> >  ct_dpif_format_entry(&cte, &s, dpctl_p->verbosity,
> > @@ -1296,6 +1296,13 @@ dpctl_dump_conntrack(int argc, const char *argv[],
> >  dpctl_print(dpctl_p, "%s\n", ds_cstr(&s));
> >  ds_destroy(&s);
> >  }
> > +if (error == EOF) {
> > +/* Any CT entry was dumped with no issue. */
> > +error = 0;
> > +} else if (error) {
> > +dpctl_error(dpctl_p, error, "dumping conntrack entry");
> > +}
> > +
> >  ct_dpif_dump_done(dump);
> >  dpif_close(dpif);
> >  return error;
> > @@ -1384,7 +1391,7 @@ dpctl_ct_stats_show(int argc, const char *argv[],
> >  }
> > 
> >  int tot_conn = 0;
> > -while (!ct_dpif_dump_next(dump, &cte)) {
> > +while (!(error = ct_dpif_dump_next(dump, &cte))) {
> >  ct_dpif_entry_uninit(&cte);
> >  tot_conn++;
> >  switch (cte.tuple_orig.ip_proto) {
> > @@ -1425,6 +1432,13 @@ dpctl_ct_stats_show(int argc, const char *argv[],
> >  break;
> >  }
> >  }
> > +if (error == EOF) {
> > +/* All CT entries were dumped with no issue.  */
> > +error = 0;
> > +} else if (error) {
> > +dpctl_error(dpctl_p, error, "dumping conntrack entry");
> > +/* Fall through to show any other info we collected. */
> > +}
> > 
> >  dpctl_print(dpctl_p, "Connections Stats:\nTotal: %d\n", tot_conn);
> >  if (proto_stats[CT_STATS_TCP]) {
> > @@ -1521,7 +1535,7 @@ dpctl_ct_bkts(int argc, const char *argv[],
> >  int tot_conn = 0;
> >  uint32_t *conn_per_bkts = xzalloc(tot_bkts * sizeof(uint32_t));
> > 
> > -while (!ct_dpif_dump_next(dump, &cte)) {
> > +while (!(error = ct_dpif_dump_next(dump, &cte))) {
> >  ct_dpif_entry_uninit(&cte);
> >  tot_conn++;
> >  if (tot_bkts > 0) {
> > @@ -1533,6 +1547,13 @@ dpctl_ct_bkts(int argc, const char *argv[],
> >  }
> >  }
> >  }
> > +if (error == EOF) {
> > +/* All CT entries were dumped with no issue.  */
> > +error = 0;
> > +} else if (error) {
> > +dpctl_error(dpctl_p, error, "dumping conntrack entry");
> > +/* Fall through and display all the collected info.  */
> > +}
> > 
> >  dpctl_print(dpctl_p, "Current Connections: %d\n", tot_conn);
> >  dpctl_print(dpctl_p, "\n");
> > --
> > 2.4.11
> > 
> > ___
> > 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v3 0/5] Conntrack: add commands to r/w CT parameters.

2017-11-03 Thread Darrell Ball
I’ll look at these in detail Ben

Thanks Darrell

On 11/3/17, 2:49 PM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" 
 wrote:

On Fri, Oct 13, 2017 at 09:25:12AM +0100, antonio.fische...@intel.com wrote:
> This change comes from the consideration that when the CT is enabled 
> the overall performance can be deeply affected, even with simple
> firewall rules and with stateless protocols like UDP.
> This implementation adds a basic infrastructure that allows the user
> to adjust the CT configuration parameters at run-time in order to
> find a better tuning.
> For example - depending on the traffic profile - the user could decrease 
> at run-time the maximum number of tracked connections, so to mitigate 
> the impact on performance.
> 
> V3: Added changes to documentation.
> 
> V2: Reworked based on comments.
> Patch #1 comes after a discussion with Darrell.
> 
> V1: First implementation.

Hi Darrell.  The userspace connection tracker is mostly your code.  Do
you want to review this series?  Otherwise, let me know, and I'll do my
best.
___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=edCCE36XXXeIHc0gj-Q0g9UV92jeGIxFHuFOdSQGwyc&s=NMnXxlgV8pDkn-5fI4MXaq0mJfdBIAD3h6ZfCmpVR8Q&e=


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


Re: [ovs-dev] [PATCH] ovs-lib: dont't purge corrupted DB

2017-11-03 Thread Ben Pfaff
On Wed, Sep 27, 2017 at 09:32:52PM +, Mark Michelson wrote:
> LGTM
> 
> On Wed, Sep 27, 2017 at 8:46 AM Matteo Croce  wrote:
> 
> > In ovs-lib there is a function named upgrade_db which tries to convert a
> > database after OVS {up,down}grades. This function uses ovsdb-tool to
> > check if the DB needs to be upgraded. If the upgrade fails,
> > it purges the DB and create an empty one.
> > ovsdb-tool returns "yes" or "no" to indicate if the DB needs upgrading,
> > but if the DB is corrupted it returns a list of errors.
> > Change a condition from "!= no" to "= yes" because in case of DB
> > corruption upgrade_db would purge the existing DB without writing
> > anything in the logs.
> >
> > Signed-off-by: Matteo Croce 
> >
> Acked-by: Mark Michelson 

Thanks Matteo and Mark, I applied this to master and branch-2.8.  If
you're concerned about older versions, let me know and I can backport it
farther.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v3 0/5] Conntrack: add commands to r/w CT parameters.

2017-11-03 Thread Ben Pfaff
On Fri, Oct 13, 2017 at 09:25:12AM +0100, antonio.fische...@intel.com wrote:
> This change comes from the consideration that when the CT is enabled 
> the overall performance can be deeply affected, even with simple
> firewall rules and with stateless protocols like UDP.
> This implementation adds a basic infrastructure that allows the user
> to adjust the CT configuration parameters at run-time in order to
> find a better tuning.
> For example - depending on the traffic profile - the user could decrease 
> at run-time the maximum number of tracked connections, so to mitigate 
> the impact on performance.
> 
> V3: Added changes to documentation.
> 
> V2: Reworked based on comments.
> Patch #1 comes after a discussion with Darrell.
> 
> V1: First implementation.

Hi Darrell.  The userspace connection tracker is mostly your code.  Do
you want to review this series?  Otherwise, let me know, and I'll do my
best.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v3 1/5] dpctl: Comment functions retrieving the datapath name.

2017-11-03 Thread Ben Pfaff
On Fri, Oct 13, 2017 at 09:25:13AM +0100, antonio.fische...@intel.com wrote:
> Add a comment to functions retrieving the datapath name.
> 
> CC: Darrell Ball 
> Signed-off-by: Antonio Fischetti 

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


Re: [ovs-dev] [PATCH] ovn: Fix remote not receive GARP, when localnet Port has vlan tag.

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 02:41:54PM -0700, Ben Pfaff wrote:
> On Fri, Oct 13, 2017 at 10:09:51PM +0800, Guoshuai Li wrote:
> > When sending a localnet port with vlan, the GARP packet needs push_vlan.
> > 
> > Signed-off-by: Guoshuai Li 
> > ---
> > 
> > v3:
> >Add garp-vlan test.
> > 
> > v2:
> >Add check vlan vaid.
> >Add update localnet vlan tag process.
> 
> Thanks a lot.  I applied this to master.  (I did change the type of
> 'tag' from int64_t to just int.)

Also, if this is causing problems for older versions of OVN, let me know
and I'll cherry-pick it to an older branch.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ovn: Fix remote not receive GARP, when localnet Port has vlan tag.

2017-11-03 Thread Ben Pfaff
On Fri, Oct 13, 2017 at 10:09:51PM +0800, Guoshuai Li wrote:
> When sending a localnet port with vlan, the GARP packet needs push_vlan.
> 
> Signed-off-by: Guoshuai Li 
> ---
> 
> v3:
>Add garp-vlan test.
> 
> v2:
>Add check vlan vaid.
>Add update localnet vlan tag process.

Thanks a lot.  I applied this to master.  (I did change the type of
'tag' from int64_t to just int.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] netdev-linux: do not remove ingress qdisc when disable policing.

2017-11-03 Thread Ben Pfaff
On Fri, Oct 13, 2017 at 02:01:07PM +0800, Guoshuai Li wrote:
> rate limiting may be implemented in other ways (such as nova),
> this time need to disable rate limiting.
> I think it should not remove tc qdisk when ingress_policing_burst
> is disabled.
> 
> Signed-off-by: Guoshuai Li 
> Co-authored-by: huweihua 

After this patch is applied, it looks to me like removing policing
becomes a complete no-op.  That cannot be right; it means that policing,
once enabled, cannot be disabled.

Can you help me understand better?

Thanks,

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


Re: [ovs-dev] [PATCH v3] dpif-netdev: Set MAX_RECIRC_DEPTH to 6.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 22, 2017 at 10:49:43PM +0800, Guoshuai Li wrote:
> In an ovn gateway node with DPDK, the RECIRC_DEPTH may be greater than 5.
> 
> Scenes:
> VM ping self floating IP, or
> VM ping Floating IP of VMs with the same network.
> 
> It need process UNDNAT SNAT in LRouter egress and
> UNSNAT DNAT in LRouter ingress, and
> output to geneve tunnel also need recirc.
> 
> This has an WARN:
> dpif_netdev(pmd36)|WARN|Packet dropped. Max recirculation depth exceeded.
> 
> Signed-off-by: Guoshuai Li 

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


Re: [ovs-dev] [PATCH v2] ovn: OVN Support QoS meter

2017-11-03 Thread Ben Pfaff
On Wed, Sep 20, 2017 at 07:52:34PM +0800, Guoshuai Li wrote:
> ovn-northd modify:
> add bandwidth column in NB's QOS table.
> add QOS_METER stages in Logical switch ingress/egress.
> add set_meter() action in SB's LFlow table.
> 
> ovn-controller modify:
> add meter_table for meter action process openflow meter table.
> 
> This feature is only supported in DPDK.

My apologies for the delayed review.  Would you mind rebasing and
reposting?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] netdev, dpif: fix the crash/assert on port delete

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 07:36:41AM -0700, Ashish Varma wrote:
> a crash is seen in "netdev_ports_remove" when an interface is deleted and 
> added
> back in the system and when the interface is part of a bridge configuration.
> e.g. steps:
>   create a tap0 interface using "ip tuntap add.."
>   add the tap0 interface to br0 using "ovs-vsctl add-port.."
>   delete the tap0 interface from system using "ip tuntap del.."
>   add the tap0 interface back in system using "ip tuntap add.."
>(this changes the ifindex of the interface)
>   delete tap0 from br0 using "ovs-vsctl del-port.."
> 
> In the function "netdev_ports_insert", two hmap entries were created for
> mapping "portnum -> netdev" and "ifindex -> portnum".
> When the interface is deleted from the system, the "netdev_ports_remove"
> function is not getting called and the old ifindex entry is not getting
> cleaned up from the "ifindex_to_port" hmap.
> 
> As part of the fix, added function "dpif_port_remove" which will call
> "netdev_ports_remove" in the path where the interface deletion from the system
> is detected.
> Also, in "netdev_ports_remove", added the code where the 
> "ifindex_to_port_data"
> (ifindex -> portnum map node) is getting freed when the ifindex is not
> available any more. (as the interface is already deleted.)
> 
> VMware-BZ: #1975788
> Signed-off-by: Ashish Varma 

Thanks for the patch.  It's good to fix a bug and especially to fix a
crash.  I'm still not entirely certain about the actual need for this
hmap, but I guess that this fixes a real problem.

This introduces new code in netdev_ports_remove() to handle the new
case.  The new case duplicates some code that I believe should be
possible to avoid duplicating.  Can you try to refactor slightly to
avoid the code duplication?

I see that this writes an expression like: (a == b) && (c == d).
Usually, in Open vSwitch, we don't add the extra parentheses unless they
are needed or clear up some genuine confusion, so that we would instead
write a == b && c == d.

Thanks,

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


[ovs-dev] [PATCH v3 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Mark Michelson
This change adds three new options to the Northbound
Logical_Router_Port's ipv6_ra_configs option:

* send_periodic: If set to "true", then OVN will send periodic router
advertisements out of this router port.
* max_interval: The maximum amount of time to wait between sending
periodic router advertisements.
* min_interval: The minimum amount of time to wait between sending
periodic router advertisements.

When send_periodic is true, then IPv6 RA configs, as well as some layer
2 and layer 3 information about the router port, are copied to the
southbound database. From there, ovn-controller can use this information
to know when to send periodic RAs and what to send in them.

Because periodic RAs originate from each ovn-controller, the new
keep-local flag is set on the packet so that ports don't receive an
overabundance of RAs.

Signed-off-by: Mark Michelson 
---
 lib/packets.h|   7 +
 ovn/controller/pinctrl.c | 341 +++
 ovn/northd/ovn-northd.c  |  65 +
 ovn/ovn-nb.xml   |  19 +++
 tests/ovn-northd.at  | 110 +++
 tests/ovn.at | 150 +
 6 files changed, 692 insertions(+)

diff --git a/lib/packets.h b/lib/packets.h
index 057935cbf..b8249047f 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -976,6 +976,7 @@ BUILD_ASSERT_DECL(ND_PREFIX_OPT_LEN == sizeof(struct 
ovs_nd_prefix_opt));
 
 /* Neighbor Discovery option: MTU. */
 #define ND_MTU_OPT_LEN 8
+#define ND_MTU_DEFAULT 0
 struct ovs_nd_mtu_opt {
 uint8_t  type;  /* ND_OPT_MTU */
 uint8_t  len;   /* Always 1. */
@@ -1015,6 +1016,12 @@ BUILD_ASSERT_DECL(RA_MSG_LEN == sizeof(struct 
ovs_ra_msg));
 #define ND_RA_MANAGED_ADDRESS 0x80
 #define ND_RA_OTHER_CONFIG0x40
 
+/* Defaults based on MaxRtrInterval and MinRtrInterval from RFC 4861 section
+ * 6.2.1
+ */
+#define ND_RA_MAX_INTERVAL_DEFAULT 600
+#define ND_RA_MIN_INTERVAL_DEFAULT(max) ((max) >= 9 ? (max) / 3 : (max) * 3 / 
4)
+
 /*
  * Use the same struct for MLD and MLD2, naming members as the defined fields 
in
  * in the corresponding version of the protocol, though they are reserved in 
the
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 29b2dde0c..428d5048f 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -48,6 +48,7 @@
 #include "socket-util.h"
 #include "timeval.h"
 #include "vswitch-idl.h"
+#include "lflow.h"
 
 VLOG_DEFINE_THIS_MODULE(pinctrl);
 
@@ -88,6 +89,11 @@ static void pinctrl_handle_put_nd_ra_opts(
 static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
  const struct match *md,
  struct ofpbuf *userdata);
+static void init_ipv6_ras(void);
+static void destroy_ipv6_ras(void);
+static void ipv6_ra_wait(void);
+static void send_ipv6_ras(const struct controller_ctx *ctx,
+struct hmap *local_datapaths);
 
 COVERAGE_DEFINE(pinctrl_drop_put_mac_binding);
 
@@ -98,6 +104,7 @@ pinctrl_init(void)
 conn_seq_no = 0;
 init_put_mac_bindings();
 init_send_garps();
+init_ipv6_ras();
 }
 
 static ovs_be32
@@ -1083,8 +1090,340 @@ pinctrl_run(struct controller_ctx *ctx,
 run_put_mac_bindings(ctx);
 send_garp_run(ctx, br_int, chassis, chassis_index, local_datapaths,
   active_tunnels);
+send_ipv6_ras(ctx, local_datapaths);
 }
 
+/* Table of ipv6_ra_state structures, keyed on logical port name */
+static struct shash ipv6_ras;
+
+/* Next IPV6 RA in seconds. */
+static long long int send_ipv6_ra_time;
+
+struct ipv6_network_prefix {
+struct in6_addr addr;
+unsigned int prefix_len;
+};
+
+struct ipv6_ra_config {
+time_t min_interval;
+time_t max_interval;
+struct eth_addr eth_src;
+struct eth_addr eth_dst;
+struct in6_addr ipv6_src;
+struct in6_addr ipv6_dst;
+ovs_be32 mtu;
+uint8_t mo_flags; /* Managed/Other flags for RAs */
+uint8_t la_flags; /* On-link/autonomous flags for address prefixes */
+struct ipv6_network_prefix *prefixes;
+int n_prefixes;
+};
+
+struct ipv6_ra_state {
+long long int next_announce;
+struct ipv6_ra_config *config;
+int64_t port_key;
+int64_t metadata;
+bool deleteme;
+};
+
+static void
+init_ipv6_ras(void)
+{
+shash_init(&ipv6_ras);
+send_ipv6_ra_time = LLONG_MAX;
+}
+
+static void
+ipv6_ra_config_delete(struct ipv6_ra_config *config)
+{
+if (config) {
+free(config->prefixes);
+}
+free(config);
+}
+
+static void
+ipv6_ra_delete(struct ipv6_ra_state *ra)
+{
+if (ra) {
+ipv6_ra_config_delete(ra->config);
+}
+free(ra);
+}
+
+static void
+destroy_ipv6_ras(void)
+{
+struct shash_node *iter, *next;
+SHASH_FOR_EACH_SAFE (iter, next, &ipv6_ras) {
+struct ipv6_ra_state *ra = iter->data;
+ipv6_ra_delete(ra);
+shash_delete(&ipv6_ras, iter);
+}
+shash_destroy(&ipv6_ras);
+}
+
+static struct ipv6_ra_config *
+ipv6_ra_update_config(const struct sbre

[ovs-dev] [PATCH v3 0/2] OVN: Add support for periodic router advertisements

2017-11-03 Thread Mark Michelson
This patch series adds support for sending periodic router
advertisements from OVN. The patch is divided into two commits

* Commit 1 introduces a method to ensure that multicast packets are sent
  only to targets on the local hypervisor
* Commit 2 adds the ability to actually send the periodic RAs.

This patch series builds on the work in Numan Siddique's "ovn IPv6: Add
Router Solicitation responder support and generate Neighbor Solicitation
request for unknown" (patch series 11416 if using git-pw). Thus this
patch series cannot be merged until that patch series is merged first.

There are a couple of points I'd like to bring up with regards to this
patch that I would like addressed in reviews:

* I placed the logic for sending periodic RAs in pinctrl.c. My reasoning
  for this was that the closest thing that exists in OVN today is the
  periodic sending of gratuitous ARP requests, and that is in pinctrl.c.
  If periodic sending of RAs should be placed into a separate file,
  please let me know.
* In this patch, you will notice that a copy of the put_load() function
  from ovn/controller/physical.c has been placed in pinctrl.c. My choice
  was either to make the function public or duplicate it. Given that the
  function is so small, I see no reason why it would be modified, I went
  with the duplication choice. However, if it should be done the other
  way, let me know and I'll go that direction instead.


v2 -> v3:
Updated patch 2 based on feedback from Jakub Sitnicki
* Fixed typo in ovn-nb.xml
* Fixed function declaration of ipv6_ra_config_delete
* Used ipv6_parse_cidr() instead of manually parsing
* Added comments explaining some non-obvious items.
* Made destructor of ipv6_ra_state NULL-safe

v1 -> v2:
* The patchset has been applied on top of patch series 11416. The cover
  letter above has been adjusted for that change.
* Patch 1 has been updated by adding new information to the
  ovn-architecture manpage that mentions the MLF_KEEP_LOCAL flows
  installed in table 32.

Mark Michelson (2):
  OVN: Add multicast keep-local flag.
  OVN: Add support for periodic router advertisements.

 lib/packets.h  |   7 +
 ovn/controller/physical.c  |  15 ++
 ovn/controller/pinctrl.c   | 341 +
 ovn/lib/logical-fields.h   |   6 +
 ovn/northd/ovn-northd.c|  65 +
 ovn/ovn-architecture.7.xml |  10 ++
 ovn/ovn-nb.xml |  19 +++
 tests/ovn-northd.at| 110 +++
 tests/ovn.at   | 150 
 9 files changed, 723 insertions(+)

-- 
2.13.5

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


[ovs-dev] [PATCH v3 1/2] OVN: Add multicast keep-local flag.

2017-11-03 Thread Mark Michelson
When this flag is set, then a multicast packet that would normally be
delivered to ports on multiple hypervisors is only delivered to ports
on the local hypervisor.

The primary known use case for this is when multicast packets originate
from ovn-controller. Multiple ovn-controllers will be attempting to send
out those multicast packets, and so each should only be responsible for
delivering those packets to their local ports.

Signed-off-by: Mark Michelson 
---
 ovn/controller/physical.c  | 15 +++
 ovn/lib/logical-fields.h   |  6 ++
 ovn/ovn-architecture.7.xml | 10 ++
 3 files changed, 31 insertions(+)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index df71979f9..b2216457f 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -995,6 +995,21 @@ physical_run(struct controller_ctx *ctx, enum mf_field_id 
mff_ovn_geneve,
 struct ofpbuf remote_ofpacts;
 ofpbuf_init(&remote_ofpacts, 0);
 SBREC_MULTICAST_GROUP_FOR_EACH (mc, ctx->ovnsb_idl) {
+/* Table 32, priority 150.
+ * ===
+ *
+ * Multicast packets that should not be sent to other hypervisors.
+ */
+struct match match = MATCH_CATCHALL_INITIALIZER;
+match_set_metadata(&match, htonll(mc->datapath->tunnel_key));
+match_set_reg(&match, MFF_LOG_OUTPORT - MFF_REG0, mc->tunnel_key);
+match_set_reg_masked(&match, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_KEEP_LOCAL, MLF_KEEP_LOCAL);
+ofpbuf_clear(&ofpacts);
+put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
+ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0, &match,
+&ofpacts);
+
 consider_mc_group(mff_ovn_geneve, ct_zones, local_datapaths, chassis,
   mc, &ofpacts, &remote_ofpacts, flow_table);
 }
diff --git a/ovn/lib/logical-fields.h b/ovn/lib/logical-fields.h
index 696c529be..eb0b8f422 100644
--- a/ovn/lib/logical-fields.h
+++ b/ovn/lib/logical-fields.h
@@ -49,6 +49,7 @@ enum mff_log_flags_bits {
 MLF_RCV_FROM_VXLAN_BIT = 1,
 MLF_FORCE_SNAT_FOR_DNAT_BIT = 2,
 MLF_FORCE_SNAT_FOR_LB_BIT = 3,
+MLF_KEEP_LOCAL_BIT = 4,
 };
 
 /* MFF_LOG_FLAGS_REG flag assignments */
@@ -69,6 +70,11 @@ enum mff_log_flags {
 /* Indicate that a packet needs a force SNAT in the gateway router when
  * load-balancing has taken place. */
 MLF_FORCE_SNAT_FOR_LB = (1 << MLF_FORCE_SNAT_FOR_LB_BIT),
+
+/* Indicate that a packet that should be distributed across multiple
+ * hypervisors should instead only be output to local targets
+ */
+MLF_KEEP_LOCAL = (1 << MLF_KEEP_LOCAL_BIT),
 };
 
 #endif /* ovn/lib/logical-fields.h */
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index b13b41177..9c7663e93 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -1027,6 +1027,16 @@
   their traffic should never go out through a tunnel.
 
 
+  A higher-priority rule to match packets that have the MLF_KEEP_LOCAL
+  logical flow flag set, and whose destination is a multicast address.
+  This flag indicates that the packet should not be delivered to remote
+  hypervisors, even if the multicast destination includes ports on
+  remote hypervisors. This flag is used when ovn-controller is the
+  originator of the multicast packet. Since each ovn-controller
+  instance is originating these packets, the packets only need to be
+  delivered to local ports.
+
+
   A fallback flow that resubmits to table 33 if there is no other
   match.
 
-- 
2.13.5

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


Re: [ovs-dev] [PATCH] OF1.5/EXT-334 OXS/Extensible Flow Entry Statistics Support

2017-11-03 Thread Ben Pfaff
On Wed, Sep 13, 2017 at 05:12:11PM +0530, SatyaValli wrote:
> From: SatyaValli 
> 
> This Patch provides implementation Existing flow entry statistics are
> redefined as standard OXS(OpenFlow Extensible Statistics) fields for
> displaying the arbitrary flow stats.The existing Flow Stats were renamed
> as Flow Description.

Thank you for doing all this work.  I have some comments.

I think that the comment on 'reserved' in struct ofp_oxs_stat is wrong.
This field should always be zero, not "One of OFPST_*.".

Why does "struct ox_fields" have a plural name?  It appear to represent
a single field.

The meaning of the new 'oxs_fields' and 'flow_desc' members in
ofputil_flow_stats_request isn't clear from the comments:

  - It looks like oxs_fields is used to append some stats to flow stats
request messages, but I can't find a description of this ability in
the OF1.5.1 spec.  I see a mention of stats in *replies* to these
messages, but not requests.  Can you help me understand?

  - I guess that 'flow_desc' distinguishes OFPMP_FLOW_DESC from
OFPMP_FLOW_STATS.  That really isn't clear from the comments.
Please edit the top-level comment for this struct to explain the
three kinds of messages it can represent and how they are
distinguished.

Names like "oxs-idle_time" are going to be hard to remember.  Do you
think that the "oxs-" prefix is really needed?  Do you think that we
could consistently use either _ or -, not a combination of both?

I don't understand this comment.  The grammar is a little funny:
+/* ofputil_flow_stats structure is used to encode/decode oxs stats
+ * fields since no stat fields are necessary in request NULL was
+ * passed */

There is a little funny indentation in
ofputil_decode_flow_stats_reply().  Please check it.

ox-stat.c seems to use a function name be64toh() on uint64_ts that
actually contain big-endian data.  Please instead use ovs_be64 and
ntohll().  Possibly a helper function or two would help.

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


[ovs-dev] Administración financiera de las cuentas por pagar

2017-11-03 Thread Técnicas Infalibles
Control de cuentas por pagar para reducir los costos e Impactos de una 
administración deficiente

Administración financiera de las cuentas por pagar
16 de noviembre - Mtra. Guillermina Barrera Zaragoza9am-8pm

No tener administración de las cuentas por pagar, no saber cuándo se debe pagar 
a los proveedores y no existir liquidez para el pago a éstos, son los 3 
problemas en específico que pueden romper la relación que una empresa tiene con 
sus proveedores, por más fuerte que parezca o por más confianza que se tenga en 
esta relación. Es importante saber que mantener una buena relación con los 
proveedores es fundamental para cualquier organización, pues de ellos depende 
su prosperidad y el suministro de sus almacenes. 

BENEFICIOS DE ASISTIR: 

a. Aprenderá las técnicas más usuales para el control de las cuentas por pagar. 
b. Adquirirá las herramientas fundamentales para el estudio y análisis de las 
políticas y procesos que les dan origen. 
c. Conocerá los elementos que permitan identificar áreas de interés y de 
oportunidad para la adecuación a cada caso específico y mejorar la 
administración de las cuentas por pagar.
 d. Apreciará los beneficios y perjuicios de la buena administración de las 
cuentas por pagar. 

¿Requiere la información a la Brevedad? responda este email con la palabra: 
Cuentas + nombre - teléfono - correo.


centro telefónico:018002120744


 


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


Re: [ovs-dev] [PATCH 1/7] ccmap: Use PADDED_MEMBERS macro in ccmap_impl structure.

2017-11-03 Thread Ben Pfaff
On Sun, Oct 01, 2017 at 08:57:34AM +0100, Bhanuprakash Bodireddy wrote:
> Instead of explicitly adding the pad bytes to force the structure an exact
> multiple of cacheline size, let the PADDED_MEMBERS macro do the job.
> 
> Signed-off-by: Bhanuprakash Bodireddy 

Thanks for the series.

I applied all of these patches to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v2] rhel: Add support for "systemctl reload openvswitch"

2017-11-03 Thread Timothy Redaelli
The reload procedure will trigger a script that saves the flows and tlv
maps (using ovs-save) then it restarts ovsdb-server, it stops ovs-vswitchd,
it sets other_config:flow-restore-wait=true (to wait till flow restore is
finished), it starts ovs-vswitchd, it restore the backupped flows/tlv
maps and it removes other_config:flow-restore-wait=true (logic mostly ripped
from ovs-ctl).

It uses systemctl with --job-mode=ignore-dependencies to restart ovsdb-server
and stop and start ovs-vswitchd in order to avoid systemd to restart the other
components due to dependencies (as explained in rhel/README.RHEL.rst).

Signed-off-by: Timothy Redaelli 
---
v1->v2:
 * Renamed the script from ovs-reload to ovs-systemd-reload
   (as suggested by Flavio Leitner)
---
 rhel/automake.mk   |  1 +
 rhel/openvswitch-fedora.spec.in|  5 +++
 rhel/usr_lib_systemd_system_openvswitch.service|  2 +-
 rhel/usr_lib_systemd_system_ovsdb-server.service   |  1 -
 ...sr_share_openvswitch_scripts_ovs-systemd-reload | 36 ++
 5 files changed, 43 insertions(+), 2 deletions(-)
 create mode 100755 rhel/usr_share_openvswitch_scripts_ovs-systemd-reload

diff --git a/rhel/automake.mk b/rhel/automake.mk
index 9336f0912..137ff4a39 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -24,6 +24,7 @@ EXTRA_DIST += \
rhel/openvswitch.spec.in \
rhel/openvswitch-fedora.spec \
rhel/openvswitch-fedora.spec.in \
+   rhel/usr_share_openvswitch_scripts_ovs-systemd-reload \
rhel/usr_share_openvswitch_scripts_sysconfig.template \
rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \
rhel/usr_lib_udev_rules.d_91-vfio.rules \
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index fb7d918c6..b45e018f5 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -314,6 +314,10 @@ install -d -m 0755 
$RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn
 ln -s %{_datadir}/openvswitch/scripts/ovndb-servers.ocf \
   $RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn/ovndb-servers
 
+install -p -D -m 0755 \
+rhel/usr_share_openvswitch_scripts_ovs-systemd-reload \
+$RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovs-systemd-reload
+
 # remove unpackaged files
 rm -f $RPM_BUILD_ROOT%{_bindir}/ovs-parse-backtrace \
 $RPM_BUILD_ROOT%{_sbindir}/ovs-vlan-bug-workaround \
@@ -539,6 +543,7 @@ fi
 %{_datadir}/openvswitch/scripts/ovs-save
 %{_datadir}/openvswitch/scripts/ovs-vtep
 %{_datadir}/openvswitch/scripts/ovs-ctl
+%{_datadir}/openvswitch/scripts/ovs-systemd-reload
 %config %{_datadir}/openvswitch/vswitch.ovsschema
 %config %{_datadir}/openvswitch/vtep.ovsschema
 %{_bindir}/ovs-appctl
diff --git a/rhel/usr_lib_systemd_system_openvswitch.service 
b/rhel/usr_lib_systemd_system_openvswitch.service
index faca44b54..feaba37d5 100644
--- a/rhel/usr_lib_systemd_system_openvswitch.service
+++ b/rhel/usr_lib_systemd_system_openvswitch.service
@@ -9,7 +9,7 @@ Requires=ovs-vswitchd.service
 [Service]
 Type=oneshot
 ExecStart=/bin/true
-ExecReload=/bin/true
+ExecReload=/usr/share/openvswitch/scripts/ovs-systemd-reload
 ExecStop=/bin/true
 RemainAfterExit=yes
 
diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index 5baac822d..234d39355 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -3,7 +3,6 @@ Description=Open vSwitch Database Unit
 After=syslog.target network-pre.target
 Before=network.target network.service
 Wants=ovs-delete-transient-ports.service
-ReloadPropagatedFrom=openvswitch.service
 PartOf=openvswitch.service
 
 [Service]
diff --git a/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload 
b/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
new file mode 100755
index 0..3ac1a46c6
--- /dev/null
+++ b/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
@@ -0,0 +1,36 @@
+#! /bin/sh
+
+# Copyright (c) 2017 Red Hat, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at:
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# Save flows
+bridges=$(ovs-vsctl -- --real list-br)
+flows=$(/usr/share/openvswitch/scripts/ovs-save save-flows $bridges)
+
+# Restart the database first, since a large database may take a
+# while to load, and we want to minimize forwarding disruption.
+systemctl --job-mode=ignore-dependencies restart ovsdb-server
+
+# Stop ovs-vswitchd.
+systemctl --job

Re: [ovs-dev] [PATCH v2 07/12] netdev-linux: Clean up netdev_linux_sock_batch_send().

2017-11-03 Thread Ben Pfaff
On Wed, Sep 20, 2017 at 02:12:56PM +0100, Bhanuprakash Bodireddy wrote:
> Use DP_PACKET_BATCH_FOR_EACH macro and dp_packet_batch_size() API
> in netdev_linux_sock_batch_send().
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH v2 10/12] odp-execute: Use const qualifer for batch size.

2017-11-03 Thread Ben Pfaff
On Wed, Sep 20, 2017 at 02:12:59PM +0100, Bhanuprakash Bodireddy wrote:
> It is recommended to use const qualifer for 'num' that tracks the
> packet batch count. This way 'num' can't be modified by iterator.
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH v2 02/12] netdev-linux: Use DP_PACKET_BATCH_FOR_EACH in netdev_linux_tap_batch_send.

2017-11-03 Thread Ben Pfaff
On Wed, Sep 20, 2017 at 02:12:51PM +0100, Bhanuprakash Bodireddy wrote:
> Use DP_PACKET_BATCH_FOR_EACH macro in netdev_linux_tap_batch_send().
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH v2 04/12] netdev-bsd: Use DP_PACKET_BATCH_FOR_EACH in netdev_bsd_send.

2017-11-03 Thread Ben Pfaff
On Wed, Sep 20, 2017 at 02:12:53PM +0100, Bhanuprakash Bodireddy wrote:
> Use DP_PACKET_BATCH_FOR_EACH macro in netdev_bsd_send().
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> ---
>  lib/netdev-bsd.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/netdev-bsd.c b/lib/netdev-bsd.c
> index 8a4cdb3..96ba71c 100644
> --- a/lib/netdev-bsd.c
> +++ b/lib/netdev-bsd.c
> @@ -685,6 +685,7 @@ netdev_bsd_send(struct netdev *netdev_, int qid 
> OVS_UNUSED,
>  {
>  struct netdev_bsd *dev = netdev_bsd_cast(netdev_);
>  const char *name = netdev_get_name(netdev_);
> +struct dp_packet *packet;
>  int error;
>  int i;
>  
> @@ -695,9 +696,9 @@ netdev_bsd_send(struct netdev *netdev_, int qid 
> OVS_UNUSED,
>  error = 0;
>  }
>  
> -for (i = 0; i < batch->count; i++) {
> -const void *data = dp_packet_data(batch->packets[i]);
> -size_t size = dp_packet_get_send_len(batch->packets[i]);
> +DP_PACKET_BATCH_FOR_EACH (packet, batch) {
> +const void *data = dp_packet_data(packet);
> +size_t size = dp_packet_get_send_len(packet);

It looks to me like this produces a duplicate variable named 'i' in an
inner scope, probably leaving the outer 'i' unused.

(I guess that DP_PACKET_BATCH_FOR_EACH should use a name other than 'i',
which has to be one of the most common variable names it could possibly
use.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v5 03/10] util: Add high resolution sleep support.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 15, 2017 at 05:40:23PM +0100, Bhanuprakash Bodireddy wrote:
> This commit introduces xnanosleep() for the threads needing high
> resolution sleep timeouts.
> 
> Signed-off-by: Bhanuprakash Bodireddy 

This is a little confusing.  The name xnanosleep() implies that its
argument would be in nanoseconds, but it's in fact in milliseconds.
Second, I don't understand why it's only implemented for Linux.

Thanks,

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


Re: [ovs-dev] [PATCH 13/13] ofproto-dpif-xlate: Fix dead assignment reported by clang.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:25PM +0100, Bhanuprakash Bodireddy wrote:
> Clang reports that value stored in to ac_offset is never read in the
> function.
> 
> Signed-off-by: Bhanuprakash Bodireddy 

It looks like this has been obsoleted by later patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 08/13] dpif-netdev: Reorder elements in dp_netdev_rxq structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:20PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in dp_netdev_rxq structure, pad bytes and a hole
> can be removed.
> 
> Before: structure size: 104, sum holes: 1, sum padbytes:4, cachelines:2
> After : structure size:  96, sum holes: 0, sum padbytes:0, cachelines:2

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


Re: [ovs-dev] [PATCH 07/13] netdev-provider: Reorder elements in netdev structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:19PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in netdev structure, holes can be removed.
> 
> Before: structure size: 88, sum holes: 10, cachelines:2
> After : structure size: 80, sum holes:  2, cachelines:2
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH 06/13] netdev-provider: Reorder element in netdev_flow_dump structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:18PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering bool in netdev_flow_dump structure, pad bytes can be
> reduced.
> 
> Before: structure size: 32, sum holes: 4, sum padbytes:7, cachelines:1
> After : structure size: 24, sum holes: 3, sum padbytes:0, cachelines:1
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH 05/13] netdev: Reorder elements in netdev_tunnel_config structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:17PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in netdev_tunnel_config structure, sum holes and
> pad bytes can be reduced.
> 
> Before: structure size: 96, sum holes: 17, pad bytes: 4, cachelines:2
> After : structure size: 80, sum holes:  5, pad bytes: 0, cachelines:2
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH 11/13] ofproto: Reorder elements in ofproto_bundle_settings structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:23PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in ofproto_bundle_settings structure, sum holes
> and pad bytes can be reduced.
> 
> Before: structure size: 96, sum holes: 13, pad bytes: 7, cachelines:2
> After : structure size: 80, sum holes:  4, pad bytes: 0, cachelines:2
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> ---
>  ofproto/ofproto.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/ofproto/ofproto.h b/ofproto/ofproto.h
> index 9e35327..2a7c1f3 100644
> --- a/ofproto/ofproto.h
> +++ b/ofproto/ofproto.h
> @@ -403,18 +403,17 @@ struct ofproto_bundle_settings {
>  size_t n_slaves;
>  
>  enum port_vlan_mode vlan_mode; /* Selects mode for vlan and trunks */
> +bool protected; /* Protected port mode */
> +bool use_priority_tags; /* Use 802.1p tag for frames in VLAN 0? */
>  uint16_t qinq_ethtype;
>  int vlan;   /* VLAN VID, except for PORT_VLAN_TRUNK. */
>  unsigned long *trunks;  /* vlan_bitmap, except for PORT_VLAN_ACCESS. 
> */
>  unsigned long *cvlans;
> -bool use_priority_tags; /* Use 802.1p tag for frames in VLAN 0? */
>  
>  struct bond_settings *bond; /* Must be nonnull iff if n_slaves > 1. */
>  
>  struct lacp_settings *lacp;  /* Nonnull to enable LACP. */
>  struct lacp_slave_settings *lacp_slaves; /* Array of n_slaves elements. 
> */
> -
> -bool protected; /* Protected port mode */
>  };

I'm planning to skip this one for the same reason as the previous patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 10/13] ofproto: Reorder elements in ofproto_ipfix_flow_exporter_options structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:22PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in ofproto_ipfix_flow_exporter_options structure,
> sum holes can be reduced significantly.
> 
> Before: structure size: 64, sum holes: 11, cachelines:1
> After : structure size: 56, sum holes:  3, cachelines:1
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> ---
>  ofproto/ofproto.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ofproto/ofproto.h b/ofproto/ofproto.h
> index 1e48e19..9e35327 100644
> --- a/ofproto/ofproto.h
> +++ b/ofproto/ofproto.h
> @@ -87,10 +87,10 @@ struct ofproto_ipfix_bridge_exporter_options {
>  
>  struct ofproto_ipfix_flow_exporter_options {
>  uint32_t collector_set_id;
> +bool enable_tunnel_sampling;
>  struct sset targets;
>  uint32_t cache_active_timeout;
>  uint32_t cache_max_flows;
> -bool enable_tunnel_sampling;
>  char *virtual_obs_id;
>  };

This is another case where performance isn't important and I think that
the current ordering is clearer, so I'll skip this one.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 09/13] dpif: Reorder elements in dpif_flow_put structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:21PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in dpif_flow_put structure, holes can be removed.
> 
> Before: structure size: 80, sum holes: 8, cachelines:2
> After : structure size: 72, sum holes: 0, cachelines:2
> 
> Signed-off-by: Bhanuprakash Bodireddy 

Thanks for the patch.  This is one case where I don't think the change
is worth it.  The structure is a little smaller, but this structure is
generally on the stack and often part of union dpif_op, and I think that
moving pmd_id to the beginning of the struct makes it look more
important than it is.  So, I'm going to skip this one.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 02/13] netdev-dummy: Reorder elements in dummy_packet_stream structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:14PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in dummy_packet_stream structure, sum holes
> can be reduced, thus saving a cache line.
> 
> Before: structure size: 784, sum holes: 56, cachelines:13
> After : structure size: 768, sum holes: 40, cachelines:12
> 
> Signed-off-by: Bhanuprakash Bodireddy 

I wouldn't normally bother optimizing code that is used only for
testing, but the reduction in cache lines is nice, so I applied this.
Thank you!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 03/13] tun-metadata: Reorder elements in tun_meta_entry structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:15PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in tun_meta_entry structure, sum holes and pad
> bytes can be reduced there by reducing the tun_table size.
> 
> Before: structure size: 56, sum holes: 4, pad bytes: 7  cachelines:1
> After : structure size: 48, sum holes: 0, pad bytes: 3, cachelines:1
> 
> Signed-off-by: Bhanuprakash Bodireddy 

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


Re: [ovs-dev] [PATCH 01/13] bond: Reorder elements in bond_slave structure.

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 06:59:13PM +0100, Bhanuprakash Bodireddy wrote:
> By reordering elements in bond_slave structure, holes can be removed and
> saves a cache line.
> 
> Before: structure size: 136, sum holes: 10, cachelines:3
> After : structure size: 128, sum holes:  2, cachelines:2
> 
> Signed-off-by: Bhanuprakash Bodireddy 

I don't think that performance is important for this structure, but I
like the reduction in size.

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


[ovs-dev] [PATCH] netdev, dpif: fix the crash/assert on port delete

2017-11-03 Thread Ashish Varma
a crash is seen in "netdev_ports_remove" when an interface is deleted and added
back in the system and when the interface is part of a bridge configuration.
e.g. steps:
  create a tap0 interface using "ip tuntap add.."
  add the tap0 interface to br0 using "ovs-vsctl add-port.."
  delete the tap0 interface from system using "ip tuntap del.."
  add the tap0 interface back in system using "ip tuntap add.."
   (this changes the ifindex of the interface)
  delete tap0 from br0 using "ovs-vsctl del-port.."

In the function "netdev_ports_insert", two hmap entries were created for
mapping "portnum -> netdev" and "ifindex -> portnum".
When the interface is deleted from the system, the "netdev_ports_remove"
function is not getting called and the old ifindex entry is not getting
cleaned up from the "ifindex_to_port" hmap.

As part of the fix, added function "dpif_port_remove" which will call
"netdev_ports_remove" in the path where the interface deletion from the system
is detected.
Also, in "netdev_ports_remove", added the code where the "ifindex_to_port_data"
(ifindex -> portnum map node) is getting freed when the ifindex is not
available any more. (as the interface is already deleted.)

VMware-BZ: #1975788
Signed-off-by: Ashish Varma 
---
 AUTHORS.rst|  1 +
 lib/dpif.c |  6 ++
 lib/dpif.h |  1 +
 lib/netdev.c   | 22 +++---
 ofproto/ofproto-dpif.c |  6 ++
 5 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index 3d61c04..7eecd54 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -62,6 +62,7 @@ Ariel Tubaltsev atubalt...@vmware.com
 Arnoldo Lutzarnoldo.lutz.guev...@hpe.com
 Arun Sharma arun.sha...@calsoftinc.com
 Aryan TaheriMonfaredaryan.taherimonfa...@uis.no
+Ashish Varmaashishvarma@gmail.com
 Ashwin Swaminathan  ashwi...@arista.com
 Babu Shanmugam  bscha...@redhat.com
 Ben Pfaff   b...@ovn.org
diff --git a/lib/dpif.c b/lib/dpif.c
index 3233bc8..6b2734b 100644
--- a/lib/dpif.c
+++ b/lib/dpif.c
@@ -623,6 +623,12 @@ dpif_port_del(struct dpif *dpif, odp_port_t port_no)
 return error;
 }
 
+int
+dpif_port_remove(struct dpif *dpif, odp_port_t port_no)
+{
+return netdev_ports_remove(port_no, dpif->dpif_class);
+}
+
 /* Makes a deep copy of 'src' into 'dst'. */
 void
 dpif_port_clone(struct dpif_port *dst, const struct dpif_port *src)
diff --git a/lib/dpif.h b/lib/dpif.h
index d9ded8b..c2d1c61 100644
--- a/lib/dpif.h
+++ b/lib/dpif.h
@@ -452,6 +452,7 @@ const char *dpif_port_open_type(const char *datapath_type,
 const char *port_type);
 int dpif_port_add(struct dpif *, struct netdev *, odp_port_t *port_nop);
 int dpif_port_del(struct dpif *, odp_port_t port_no);
+int dpif_port_remove(struct dpif *, odp_port_t port_no);
 
 /* A port within a datapath.
  *
diff --git a/lib/netdev.c b/lib/netdev.c
index 704b38f..954da92 100644
--- a/lib/netdev.c
+++ b/lib/netdev.c
@@ -2179,6 +2179,7 @@ struct ifindex_to_port_data {
 struct hmap_node node;
 int ifindex;
 odp_port_t port;
+const struct dpif_class *dpif_class;
 };
 
 #define NETDEV_PORTS_HASH_INT(port, dpif) \
@@ -2228,6 +2229,7 @@ netdev_ports_insert(struct netdev *netdev, const struct 
dpif_class *dpif_class,
 ifidx = xzalloc(sizeof *ifidx);
 ifidx->ifindex = ifindex;
 ifidx->port = dpif_port->port_no;
+ifidx->dpif_class = dpif_class;
 
 hmap_insert(&port_to_netdev, &data->node, hash);
 hmap_insert(&ifindex_to_port, &ifidx->node, ifidx->ifindex);
@@ -2266,10 +2268,9 @@ netdev_ports_remove(odp_port_t port_no, const struct 
dpif_class *dpif_class)
 
 if (data) {
 int ifindex = netdev_get_ifindex(data->netdev);
+struct ifindex_to_port_data *ifidx = NULL;
 
 if (ifindex > 0) {
-struct ifindex_to_port_data *ifidx = NULL;
-
 HMAP_FOR_EACH_WITH_HASH (ifidx, node, ifindex, &ifindex_to_port) {
 if (ifidx->port == port_no) {
 hmap_remove(&ifindex_to_port, &ifidx->node);
@@ -2279,11 +2280,18 @@ netdev_ports_remove(odp_port_t port_no, const struct 
dpif_class *dpif_class)
 }
 ovs_assert(ifidx);
 } else {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
-
-VLOG_WARN_RL(&rl, "netdev ports map has dpif port %"PRIu32
- " but netdev has no ifindex: %s", port_no,
- ovs_strerror(ifindex));
+/* case where the interface is already deleted form the datapath
+ * (e.g. tunctl -d or ip tuntap del), then the ifindex is not
+ * valid anymore. Traverse the HMAP for the port number. */
+HMAP_FOR_EACH (ifidx, node, &ifindex_to_port) {
+if ((ifidx->port == port_no) &&
+(ifidx->dpif_cl

Re: [ovs-dev] [PATCH] put bundle_lookup ahead to simplify the code

2017-11-03 Thread Ben Pfaff
On Tue, Sep 12, 2017 at 02:31:07PM -0700, Greg Rose wrote:
> On 09/07/2017 06:51 PM, Duan Jiong wrote:
> > From ba48275f8bb30ed2888c16426726ee9cb3407cd1 Mon Sep 17 00:00:00 2001
> >From: Duan Jiong 
> >Date: Fri, 8 Sep 2017 09:48:59 +0800
> >Subject: [PATCH] put bundle_lookup ahead to simplify the code
> >
> >Signed-off-by: Duan Jiong 
> >---
> >  ofproto/ofproto-dpif.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> >diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> >index 1a8e829..293780f 100644
> >--- a/ofproto/ofproto-dpif.c
> >+++ b/ofproto/ofproto-dpif.c
> >@@ -3011,15 +3011,16 @@ bundle_set(struct ofproto *ofproto_, void *aux,
> >  size_t i;
> >  bool ok;
> >
> >+bundle = bundle_lookup(ofproto, aux);
> >+
> >  if (!s) {
> >-bundle_destroy(bundle_lookup(ofproto, aux));
> >+bundle_destroy(bundle);
> >  return 0;
> >  }
> >
> >  ovs_assert(s->n_slaves == 1 || s->bond != NULL);
> >  ovs_assert((s->lacp != NULL) == (s->lacp_slaves != NULL));
> >
> >-bundle = bundle_lookup(ofproto, aux);
> >  if (!bundle) {
> >  bundle = xmalloc(sizeof *bundle);
> >
> 
> Makes sense...
> 
> Reviewed-by: Greg Rose 

I applied this to master.  Thanks, Duan and Greg.

(Again, I apologize for the delay.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] fix the comment in struct ofbundle

2017-11-03 Thread Ben Pfaff
On Fri, Sep 08, 2017 at 09:34:07AM +0800, Duan Jiong wrote:
> From 415ad9ffdb57a012729bef4ff19d1dc7b5b4cbcd Mon Sep 17 00:00:00 2001
> From: Duan Jiong 
> Date: Fri, 8 Sep 2017 09:30:31 +0800
> Subject: [PATCH] fix the comment in struct ofbundle
> 
> the ovs_list ports should contain struct ofport_dpif
> 
> Signed-off-by: Duan Jiong 

Thanks for the fix.  I applied this to master.

(I apologize that it took so long to review this.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 0/8] Add minimum network namespace support.

2017-11-03 Thread Ben Pfaff
On Thu, Nov 02, 2017 at 05:05:01PM -0200, Flavio Leitner wrote:
> Today Open vSwitch doesn't know about network namespaces (netns), but
> users are moving internal ports to other namespaces.  Although packets
> are still flowing, the daemon fails to find out basic port information,
> like if it is UP or DOWN, for instance.
> 
> This patchset rely on a new kernel vport API being proposed to netdev to
> find out the new network namespace ID of a bridge's port. This information
> along with the port's name recorded in the database is used to match the
> corresponding netlink messages.
> 
> This patchset also leverages another kernel API that allows the daemon
> to listen to all netlink messages from all netns which has an ID assigned
> into it.  This and the previous change allows the userspace to track ports
> in other network namespaces.
> 
> If any of the APIs aren't available, it falls back to the older APIs to
> not break backwards compatibility.

This seems like a very reasonable series to me, although I have not
reviewed it in detail.  Thank you for doing this work.

I'm hoping that Jiri or another Linux networking expert will take a look
at this series before me.  Jiri, are you planning to do that?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] rhel: Add support for "systemctl reload openvswitch"

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 07:26:05PM +0100, Timothy M. Redaelli wrote:
> On 11/03/2017 07:20 PM, Ben Pfaff wrote:
> [...]
> >>
> >> This looks good to me, my only comment is that the script is in rhel/
> >> and uses systemd so maybe we should reflect that in the script's name?
> >> Because OVS itself might provide an ovs-reload too and then we will
> >> have issues.
> >>
> >> What do you think?
> > 
> > Is this script reasonably generic, as opposed to RHEL-specific?  If so
> > then we could move it into utilities or make it a command under ovs-ctl.
> 
> Unlucky this is specific for RHEL (and derivates) since Debian/Ubuntu
> uses only one service file for both ovsdb-server and ovs-vswitchd and so
> this script can't work, but I think they can use "ovs-ctl restart" that
> have the same behavior when you don't have multiple systemd service files.

OK.  If Debian/Ubuntu changes someday, we can reconsider.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 4/4] ofp-actions: Add compare to offsetof need for MSVC 2015/17

2017-11-03 Thread Ben Pfaff
On Wed, Nov 01, 2017 at 07:19:07PM +0200, Alin Gabriel Serdean wrote:
> Unfortunately starting from VS 2015, the "C" definition for `offsetof`
> has been changed. Please see:
> https://stackoverflow.com/questions/42725929/using-offsetof-with-enum-does-not-compile-in-visual-studio-2015/42726424
> 
> Several people reported the bug for 2015 and also 2017 (i.e. :
> https://developercommunity.visualstudio.com/content/problem/22196/static-assert-cannot-compile-constexprs-method-tha.html
> ), but we don't have a fix yet.
> 
> This patch adds an explicit compare, although we could redefine the macro
> for the same effect.
> 
> Signed-off-by: Alin Gabriel Serdean 

That's super weird.

If this solves the problem, it's fine with me.

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


Re: [ovs-dev] [PATCH 3/4] build-windows: Add check for struct timespec

2017-11-03 Thread Ben Pfaff
On Wed, Nov 01, 2017 at 07:19:06PM +0200, Alin Gabriel Serdean wrote:
> Starting from WDK 10 the structure `timespec` is defined in .
> 
> This patch adds a check for the structure to make  aware of it, so
> it doesn't try to redefine the structure.
> 
> Signed-off-by: Alin Gabriel Serdean 
> ---
>  m4/openvswitch.m4 | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/m4/openvswitch.m4 b/m4/openvswitch.m4
> index 59e1352..01d2269 100644
> --- a/m4/openvswitch.m4
> +++ b/m4/openvswitch.m4
> @@ -143,6 +143,7 @@ AC_DEFUN([OVS_CHECK_WIN32],
>)
>  
>AC_DEFINE([WIN32], [1], [Define to 1 if building on WIN32.])
> +  AC_CHECK_TYPES([struct timespec], [], [], [[#include ]])
>AH_BOTTOM([#ifdef WIN32
>  #include "include/windows/windefs.h"
>  #endif])

Is this something that the Windows pthread we recommend checks for?  I
don't see any checks for it in the OVS codebase itself.

If so,
Acked-by: Ben Pfaff 

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


Re: [ovs-dev] [PATCH 2/4] windows: Add interlocked function definitions for VS 2015

2017-11-03 Thread Ben Pfaff
On Wed, Nov 01, 2017 at 07:19:05PM +0200, Alin Gabriel Serdean wrote:
> For some unclear and accidental reasons, the Windows 10 SDK
> renamed _Interlocked* functions to _InlineInterlocked* (although the
> documentation still points to the old form:
> https://msdn.microsoft.com/en-us/library/191ca0sk.aspx).
> 
> This patch adds mappings for used functions.
> 
> Signed-off-by: Alin Gabriel Serdean 

How odd.  I'll take your word for it.

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


Re: [ovs-dev] [PATCH 1/4] windows: _set_output_format is no longer required from VS2015

2017-11-03 Thread Ben Pfaff
On Wed, Nov 01, 2017 at 07:19:04PM +0200, Alin Gabriel Serdean wrote:
> _set_output_format is deprecated ang no longer required
> starting from MSC_VER 1900 (VS 2015):
> https://msdn.microsoft.com/en-us/library/bb531344(v=vs.140).aspx .
> 
> Signed-off-by: Alin Gabriel Serdean 

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


Re: [ovs-dev] Few issues in my raft testing

2017-11-03 Thread Ben Pfaff
To start, I added this to my TODO file on that branch ;-)

On Fri, Nov 03, 2017 at 11:22:19AM -0700, Ben Pfaff wrote:
> Thanks a lot for the reports.  I'll see what I can do.
> 
> On Fri, Nov 03, 2017 at 10:05:02PM +0530, Numan Siddique wrote:
> > Hi Ben,
> > 
> > I have noticed a couple of issues when testing raft support in
> > ovsdb-server. I am testing from your ovs-reviews/raft9 repo.
> > 
> > 1) As I had mentioned in the IRC meeting yesterday, when I pass the options
> > "--remote=db:OVN_Northbound,NB_Global,connections" to ovsdb-server, it is
> > failing with the error
> > "ovsdb-server: "db:OVN_Northbound,NB_Global,connections": no table named
> > NB_Global".
> > 
> > I see this issue when I freshly create the database file (ovsdb-tool
> > create-cluster ovnnb.db OVN_Northbound local_addr remote_addr" and start
> > ovsdb-server) and start the ovsdb-server.
> > 
> > This issue is not seen if the ovsdb-server has already connected to the
> > remote and the above option is passed in subsequent runs.
> > 
> > 
> > b) I am seeing an issue when I run  "ovn-nbctl ls-add sw2". It hangs.
> > 
> > I created a 2 node cluster - node 1 and node 2
> >  When I run "ovn-nbctl ls-add sw2" it hangs. Here are the steps
> >1. On node 1 created a clustered db and started ovsdb-server
> >  (/usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
> > --db-nb-cluster-local-addr=tcp:192.168.121.91:6643
> > --db-sb-cluster-local-addr=tcp:192.168.121.91:6644)
> >2. Created a logical switch "ovn-nbctl ls-add sw0"
> > 
> >3. On node 2, started ovsdb-servers as
> >  /usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
> > --db-nb-cluster-local-addr=tcp:192.168.121.87:6643
> > --db-sb-cluster-local-addr=tcp:192.168.121.87:6644
> > --db-nb-cluster-remote-addr=tcp:192.168.121.91:6643
> > --db-sb-cluster-remote-addr=tcp:192.168.121.91:6644
> > 
> >   4. "ovn-nbctl show" works fine. Ran "ovn-nbctl ls-add sw1" and it worked
> > fine.
> > 
> >   5. Stop ovsdb-server - /usr/share/openvswitch/scripts/ovn-ctl stop_ovsdb
> > 
> >   6. Start again and when I run "ovn-nbctl ls-add sw2" it hangs.
> >You can find the logs of ovsdb-server for node 2 here -
> > https://paste.fedoraproject.org/paste/xp~8lxdoq52TO28NbGoQbg
> > 
> >and node 1 here -
> > https://paste.fedoraproject.org/paste/~J4rG9H36GWWWav98N5KaQ
> > 
> > 
> > Thanks
> > Numan
> > ___
> > 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] Open Stack Users List

2017-11-03 Thread Sally Davis


Hello Good Day,

I would like to know if you are interested in acquiring Open Stack Users List.

Information fields: Names, Title, Email, Phone, Company Name, Company URL, 
Company physical address, SIC Code, Industry, Company Size (Revenue and 
Employee).
Let me know if you are interested and I will get back to you with the counts 
and pricing.

Regards,
Sally Davis
Data Consultant
To opt out, please reply with Leave Out in the Subject Line.

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


Re: [ovs-dev] [PATCH] lib: Remove lib/pool-loop.h from lib_libopenvswitch_la_SOURCES

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 07:18:05PM +0100, Timothy Redaelli wrote:
> lib/pool-loop.h is moved to to include/openvswitch, but lib/pool-loop.h
> is still used in lib_libopenvswitch_la_SOURCES.
> 
> This commit removes lib/pool-loop.h from lib_libopenvswitch_la_SOURCES.
> 
> CC: Xiao Liang 
> Fixes: fd016ae3fb84 ("lib: Move lib/poll-loop.h to include/openvswitch")
> Signed-off-by: Timothy Redaelli 

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


Re: [ovs-dev] [PATCH 1/8] netlink: provide network namespace id from a msg.

2017-11-03 Thread Ben Pfaff
On Thu, Nov 02, 2017 at 05:05:02PM -0200, Flavio Leitner wrote:
> The netlink notification's ancillary data contains the network
> namespace id (netnsid) needed to identify the device correctly.
> (ifindex and netnsid).
> 
> Signed-off-by: Flavio Leitner 

Thanks a lot for working on this.

I did not fully review this patch, but one thing that would make me more
comfortable with cmsg handling is if the code would identify SCM_RIGHTS
cmsgs and close the fds that they contain.  I don't know currently
whether the kernel ever sends fds to userspace over netlink cmsgs, but
for unix domain socket messages sent between user processes it is risky
to accept cmsg data without closing any received fds: it makes the
receiving process prone to fd leaks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] rhel: Add support for "systemctl reload openvswitch"

2017-11-03 Thread Timothy M. Redaelli
On 11/03/2017 07:20 PM, Ben Pfaff wrote:
[...]
>>
>> This looks good to me, my only comment is that the script is in rhel/
>> and uses systemd so maybe we should reflect that in the script's name?
>> Because OVS itself might provide an ovs-reload too and then we will
>> have issues.
>>
>> What do you think?
> 
> Is this script reasonably generic, as opposed to RHEL-specific?  If so
> then we could move it into utilities or make it a command under ovs-ctl.

Unlucky this is specific for RHEL (and derivates) since Debian/Ubuntu
uses only one service file for both ovsdb-server and ovs-vswitchd and so
this script can't work, but I think they can use "ovs-ctl restart" that
have the same behavior when you don't have multiple systemd service files.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] Few issues in my raft testing

2017-11-03 Thread Ben Pfaff
Thanks a lot for the reports.  I'll see what I can do.

On Fri, Nov 03, 2017 at 10:05:02PM +0530, Numan Siddique wrote:
> Hi Ben,
> 
> I have noticed a couple of issues when testing raft support in
> ovsdb-server. I am testing from your ovs-reviews/raft9 repo.
> 
> 1) As I had mentioned in the IRC meeting yesterday, when I pass the options
> "--remote=db:OVN_Northbound,NB_Global,connections" to ovsdb-server, it is
> failing with the error
> "ovsdb-server: "db:OVN_Northbound,NB_Global,connections": no table named
> NB_Global".
> 
> I see this issue when I freshly create the database file (ovsdb-tool
> create-cluster ovnnb.db OVN_Northbound local_addr remote_addr" and start
> ovsdb-server) and start the ovsdb-server.
> 
> This issue is not seen if the ovsdb-server has already connected to the
> remote and the above option is passed in subsequent runs.
> 
> 
> b) I am seeing an issue when I run  "ovn-nbctl ls-add sw2". It hangs.
> 
> I created a 2 node cluster - node 1 and node 2
>  When I run "ovn-nbctl ls-add sw2" it hangs. Here are the steps
>1. On node 1 created a clustered db and started ovsdb-server
>  (/usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
> --db-nb-cluster-local-addr=tcp:192.168.121.91:6643
> --db-sb-cluster-local-addr=tcp:192.168.121.91:6644)
>2. Created a logical switch "ovn-nbctl ls-add sw0"
> 
>3. On node 2, started ovsdb-servers as
>  /usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
> --db-nb-cluster-local-addr=tcp:192.168.121.87:6643
> --db-sb-cluster-local-addr=tcp:192.168.121.87:6644
> --db-nb-cluster-remote-addr=tcp:192.168.121.91:6643
> --db-sb-cluster-remote-addr=tcp:192.168.121.91:6644
> 
>   4. "ovn-nbctl show" works fine. Ran "ovn-nbctl ls-add sw1" and it worked
> fine.
> 
>   5. Stop ovsdb-server - /usr/share/openvswitch/scripts/ovn-ctl stop_ovsdb
> 
>   6. Start again and when I run "ovn-nbctl ls-add sw2" it hangs.
>You can find the logs of ovsdb-server for node 2 here -
> https://paste.fedoraproject.org/paste/xp~8lxdoq52TO28NbGoQbg
> 
>and node 1 here -
> https://paste.fedoraproject.org/paste/~J4rG9H36GWWWav98N5KaQ
> 
> 
> Thanks
> Numan
> ___
> 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


Re: [ovs-dev] [PATCH] rhel: Add support for "systemctl reload openvswitch"

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 01:55:00PM -0200, Flavio Leitner wrote:
> On Tue, 31 Oct 2017 12:11:32 +0100
> Timothy Redaelli  wrote:
> 
> > The reload procedure will trigger a script that saves the flows and tlv
> > maps (using ovs-save) then it restarts ovsdb-server, it stops ovs-vswitchd,
> > it sets other_config:flow-restore-wait=true (to wait till flow restore is
> > finished), it starts ovs-vswitchd, it restore the backupped flows/tlv
> > maps and it removes other_config:flow-restore-wait=true (logic mostly ripped
> > from ovs-ctl).
> > 
> > It uses systemctl with --job-mode=ignore-dependencies to restart 
> > ovsdb-server
> > and stop and start ovs-vswitchd in order to avoid systemd to restart the 
> > other
> > components due to dependencies (as explained in rhel/README.RHEL.rst).
> > 
> > Signed-off-by: Timothy Redaelli 
> > ---
> >  rhel/automake.mk |  1 +
> >  rhel/openvswitch-fedora.spec.in  |  5 
> >  rhel/usr_lib_systemd_system_openvswitch.service  |  2 +-
> >  rhel/usr_lib_systemd_system_ovsdb-server.service |  1 -
> >  rhel/usr_share_openvswitch_scripts_ovs-reload| 36 
> > 
> >  5 files changed, 43 insertions(+), 2 deletions(-)
> >  create mode 100755 rhel/usr_share_openvswitch_scripts_ovs-reload
> > 
> > diff --git a/rhel/automake.mk b/rhel/automake.mk
> > index 9336f0912..0955dceed 100644
> > --- a/rhel/automake.mk
> > +++ b/rhel/automake.mk
> > @@ -24,6 +24,7 @@ EXTRA_DIST += \
> > rhel/openvswitch.spec.in \
> > rhel/openvswitch-fedora.spec \
> > rhel/openvswitch-fedora.spec.in \
> > +   rhel/usr_share_openvswitch_scripts_ovs-reload \
> > rhel/usr_share_openvswitch_scripts_sysconfig.template \
> > rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \
> > rhel/usr_lib_udev_rules.d_91-vfio.rules \
> > diff --git a/rhel/openvswitch-fedora.spec.in 
> > b/rhel/openvswitch-fedora.spec.in
> > index fb7d918c6..87bec39c9 100644
> > --- a/rhel/openvswitch-fedora.spec.in
> > +++ b/rhel/openvswitch-fedora.spec.in
> > @@ -314,6 +314,10 @@ install -d -m 0755 
> > $RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn
> >  ln -s %{_datadir}/openvswitch/scripts/ovndb-servers.ocf \
> >$RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn/ovndb-servers
> >  
> > +install -p -D -m 0755 \
> > +rhel/usr_share_openvswitch_scripts_ovs-reload \
> > +$RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovs-reload
> > +
> >  # remove unpackaged files
> >  rm -f $RPM_BUILD_ROOT%{_bindir}/ovs-parse-backtrace \
> >  $RPM_BUILD_ROOT%{_sbindir}/ovs-vlan-bug-workaround \
> > @@ -539,6 +543,7 @@ fi
> >  %{_datadir}/openvswitch/scripts/ovs-save
> >  %{_datadir}/openvswitch/scripts/ovs-vtep
> >  %{_datadir}/openvswitch/scripts/ovs-ctl
> > +%{_datadir}/openvswitch/scripts/ovs-reload
> >  %config %{_datadir}/openvswitch/vswitch.ovsschema
> >  %config %{_datadir}/openvswitch/vtep.ovsschema
> >  %{_bindir}/ovs-appctl
> > diff --git a/rhel/usr_lib_systemd_system_openvswitch.service 
> > b/rhel/usr_lib_systemd_system_openvswitch.service
> > index faca44b54..2cf29f0e9 100644
> > --- a/rhel/usr_lib_systemd_system_openvswitch.service
> > +++ b/rhel/usr_lib_systemd_system_openvswitch.service
> > @@ -9,7 +9,7 @@ Requires=ovs-vswitchd.service
> >  [Service]
> >  Type=oneshot
> >  ExecStart=/bin/true
> > -ExecReload=/bin/true
> > +ExecReload=/usr/share/openvswitch/scripts/ovs-reload
> >  ExecStop=/bin/true
> >  RemainAfterExit=yes
> >  
> > diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
> > b/rhel/usr_lib_systemd_system_ovsdb-server.service
> > index 5baac822d..234d39355 100644
> > --- a/rhel/usr_lib_systemd_system_ovsdb-server.service
> > +++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
> > @@ -3,7 +3,6 @@ Description=Open vSwitch Database Unit
> >  After=syslog.target network-pre.target
> >  Before=network.target network.service
> >  Wants=ovs-delete-transient-ports.service
> > -ReloadPropagatedFrom=openvswitch.service
> >  PartOf=openvswitch.service
> >  
> >  [Service]
> > diff --git a/rhel/usr_share_openvswitch_scripts_ovs-reload 
> > b/rhel/usr_share_openvswitch_scripts_ovs-reload
> > new file mode 100755
> > index 0..3ac1a46c6
> > --- /dev/null
> > +++ b/rhel/usr_share_openvswitch_scripts_ovs-reload
> > @@ -0,0 +1,36 @@
> > +#! /bin/sh
> > +
> > +# Copyright (c) 2017 Red Hat, Inc.
> > +#
> > +# Licensed under the Apache License, Version 2.0 (the "License");
> > +# you may not use this file except in compliance with the License.
> > +# You may obtain a copy of the License at:
> > +#
> > +# http://www.apache.org/licenses/LICENSE-2.0
> > +#
> > +# Unless required by applicable law or agreed to in writing, software
> > +# distributed under the License is distributed on an "AS IS" BASIS,
> > +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > +# See the License for the specific language governing permissions and
> > +# limitations under the License.
>

[ovs-dev] [PATCH] lib: Remove lib/pool-loop.h from lib_libopenvswitch_la_SOURCES

2017-11-03 Thread Timothy Redaelli
lib/pool-loop.h is moved to to include/openvswitch, but lib/pool-loop.h
is still used in lib_libopenvswitch_la_SOURCES.

This commit removes lib/pool-loop.h from lib_libopenvswitch_la_SOURCES.

CC: Xiao Liang 
Fixes: fd016ae3fb84 ("lib: Move lib/poll-loop.h to include/openvswitch")
Signed-off-by: Timothy Redaelli 
---

Without this commit is not possible to do, at least, "make rpm-fedora":

# make rpm-fedora
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory `/root/ovs'
make[1]: *** No rule to make target `lib/poll-loop.h', needed by `distdir'.  
Stop.
make[1]: Leaving directory `/root/ovs'
make: *** [dist] Error 2
#

---
 lib/automake.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/automake.mk b/lib/automake.mk
index b984a759a..effe5b5c2 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -206,7 +206,6 @@ lib_libopenvswitch_la_SOURCES = \
lib/perf-counter.h \
lib/perf-counter.c \
lib/poll-loop.c \
-   lib/poll-loop.h \
lib/process.c \
lib/process.h \
lib/pvector.c \
-- 
2.14.2

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


Re: [ovs-dev] [PATCH v2 1/5] dpif-netdev: Basic CD feature with scalar lookup.

2017-11-03 Thread Ben Pfaff
On Tue, Oct 31, 2017 at 04:39:33PM -0700, Yipeng Wang wrote:
> Cuckoo distributor (CD) is a double-hash function hash table, that helps
> redirect packets to their corresponding subtables to avoid the sequential
> search of megaflow subtables.  This is another layer of cache to cache flows
> and their corresponding subtable indexes.  Different from a hash table, CD
> can have certain false positive rate (since the full key is not stored for
> space efficiency).  Our CD design was partially inspired by earlier concepts
> proposed in "simTable"[1] and "Cuckoo Filter"[2], and DPDK's cuckoo hash
> implementation.
> 
> For the current implementation, the design does not allow displacing items
> when a bucket is full, which is different from the behavior of a cuckoo hash
> table.  The advantage is that we do not need to store two signatures so that
> the struct is more compact.  We use 16 entries per bucket for the
> convenience of vector lookup.
> 
> Each classifier has its own cuckoo distributor.
> 
> [1] H. Lee and B. Lee, Approaches for improving tuple space search-based
> table lookup, ICTC '15
> [2] B. Fan, D. G. Andersen, M. Kaminsky, and M. D. Mitzenmacher,
> Cuckoo Filter: Practically Better Than Bloom, CoNEXT '14
> 
> CC: Darrell Ball 
> CC: Jan Scheurich 
> Signed-off-by: Yipeng Wang 
> Signed-off-by: Antonio Fischetti 
> Co-authored-by: Antonio Fischetti 
> ---
> Evaluation:
> We create set of rules with various src IP. We feed traffic containing 1M
> flows with various src IP and dst IP. All the flows hit 10/20/30
> rules creating 10/20/30 subtables.
> 
> The table below shows the preliminary continuous testing results (full line
> speed test) we collected with a uni-directional phy-to-phy setup. OvS
> runs with 1 PMD. We use Spirent as the hardware traffic generator.
> 
> Scalar CD results:
> 1M flows:
> no.subtable: 10  20  30
> cd-ovs   3658328 3028111 2863329
> orig_ovs 2683455 1646227 1240501
> speedup  1.36x   1.84x   2.31x

Thank you for the evaluation results.  I think that they should be
included in the commit message.  They are helpful in looking through the
commits later.

Did you consider adding the cuckoo distributor as part of a new source
file?  dpif-netdev is very big, which makes it harder to understand.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v2 0/5] dpif-netdev: Cuckoo-Distributor implementation

2017-11-03 Thread Ben Pfaff
Is this something that should be included in the repo?

On Fri, Nov 03, 2017 at 04:14:56PM +, Wang, Yipeng1 wrote:
> To make it easier for the code reviewers to build and test the patchset, a 
> TREX profile that presents a very simple synthetic test case of random 
> traffic with 20 different IP src and 50K different IP dst is attached. It can 
> be used together with the rule set we mentioned in cover letter to generate 
> uniform distribution of hits among the 20 subtables. This synthetic traffic 
> pattern  represents the worst-case scenario for the current subtable ranking 
> method.  We observe about 2x speedup vs. the original OvS in this case. Note 
> that the patchset automatically detects if there is benefit to turn CD on or 
> off to accommodate any traffic pattern, so when the subtable ranking works 
> perfectly, CD will not be enabled and will not harm the performance.
> 
> One can change the dstip and srcip_cnt variables to generate different number 
> of flows and subtable count scenarios.
> 
>  
> import locale, sys, time
> from signal import *
> 
> import stl_path
> from trex_stl_lib.api import *
> 
> [tx_port, rx_port] = my_ports = [0, 1]
> tx_ports = [tx_port]
> rx_ports = [rx_port]
> 
> global c
> 
> # dst IP vary from 0.0.0.0 to 0.0.195.255 is about 50k flows.
> # src IP vary from 1.0.0.0 to 20.0.0.0 is 20 flows.
> # 50k * 20 is about 1M total flows
> dstip = "0.0.195.255"
> srcip_cnt = 20
> size = 64
> 
> #create stream blocks. Each stream has one srcIP with various dstIP.
> #There are in total of 20 different srcIP.
> def make_streams():
> streams = [
> {"base_pkt":Ether()/IP(src="{}.0.0.0".format(i), tos=0x20)/UDP(),
>  "vm":[
> 
> STLVmFlowVar(name="ip_dst",min_value="0.0.0.0",max_value=dstip,size=4,op="random"),
> STLVmWrFlowVar(fv_name="ip_dst",pkt_offset="IP.dst"),
> ]
> }
> for i in range(1,srcip_cnt + 1)
> ]
> return streams
> 
> if __name__ == "__main__":
> 
> c = STLClient(verbose_level = LoggerApi.VERBOSE_QUIET)
> c.connect()
> 
> c.reset(ports = my_ports)
> new_streams = make_streams()
> 
> for s in new_streams:
> # 64 - 4 for FCS
> pad = max(0, size - 4 - len(s["base_pkt"])) * 'x'
> s["base_pkt"] = s["base_pkt"]/pad
> 
> pkts = [STLPktBuilder(pkt = s["base_pkt"], vm = s["vm"]) for s in 
> new_streams]
> 
> #generate contiguous traffic. Each stream has equal bandwidth.
> final_streams = [STLStream(packet = pkt, mode = STLTXCont(percentage 
> = 100.0/len(pkts))) for pkt in pkts]
> c.add_streams(final_streams, ports=[tx_port])
> c.set_port_attr(my_ports, promiscuous = True)
> 
> #start the traffic
> c.start(ports = tx_ports)
> #wait for 20 seconds
> time.sleep(20)
> #write rx pps to stdio
> sys.stdout.write(str("RX PPS: 
> ")+str(int(c.get_stats(my_ports)[1]["rx_pps"])) + str("\n"))
> #stop the traffic
> c.stop(ports=my_ports)
> c.disconnect()
> c = None
>  
> 
> 
> > -Original Message-
> > From: Wang, Yipeng1
> > Sent: Tuesday, October 31, 2017 4:40 PM
> > To: d...@openvswitch.org
> > Cc: Wang, Yipeng1 ; Gobriel, Sameh
> > ; Fischetti, Antonio
> > ; db...@vmware.com;
> > jan.scheur...@ericsson.com
> > Subject: [PATCH v2 0/5] dpif-netdev: Cuckoo-Distributor implementation
> > 
> > The Datapath Classifier uses tuple space search for flow classification.
> > The rules are arranged into a set of tuples/subtables (each with a
> > distinct mask).  Each subtable is implemented as a hash table and lookup
> > is done with flow keys formed by selecting the bits from the packet header
> > based on each subtable's mask. Tuple space search will sequentially search
> > each subtable until a match is found. With a large number of subtables, a
> > sequential search of the subtables could consume a lot of CPU cycles. In
> > a testbench with a uniform traffic pattern equally distributed across 20
> > subtables, we measured that up to 65% of total execution time is attributed
> > to the megaflow cache lookup.
> > 
> > This patch presents the idea of the two-layer hierarchical lookup, where a
> > low overhead first level of indirection is accessed first, we call this
> > level cuckoo distributor (CD). If a flow key has been inserted in the flow
> > table the first level will indicate with high probability that which
> > subtable to look into. A lookup is performed on the second level (the
> > target subtable) to retrieve the result. If the key doesn’t have a match,
> > then we revert back to the sequential search of subtables. The patch is
> > partially inspired by earlier concepts proposed in "simTable"[1] and
> > "Cuckoo Filter"[2], and DPDK's Cuckoo Hash implementation.
> > 
> > This patch can improve the already existing Subtable Ranking when traffic
> > data has high entropy. Subtable Ranking helps

Re: [ovs-dev] [PATCH v2 5/5] unit-test: Add a delay for CD initialization.

2017-11-03 Thread Ben Pfaff
On Tue, Oct 31, 2017 at 04:39:37PM -0700, Yipeng Wang wrote:
> This patch adds a delay during test 1215 for considering CD
> initialization time.
> 
> CC: Darrell Ball 
> CC: Jan Scheurich 
> Signed-off-by: Yipeng Wang 
> Signed-off-by: Antonio Fischetti 
> Co-authored-by: Antonio Fischetti 
> ---
>  tests/ofproto-dpif.at | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
> index c75a1ac..8b55454 100644
> --- a/tests/ofproto-dpif.at
> +++ b/tests/ofproto-dpif.at
> @@ -9596,6 +9596,9 @@ AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
>  dnl Start a new connection from port 1.
>  AT_CHECK([ovs-appctl netdev-dummy/receive p1 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.1.1.1,dst=10.1.1.2,proto=17,tos=0,ttl=64,frag=no),udp(src=1,dst=2)'])
>  
> +# cuckoo distributor requires time for initilization, add sleep
> +sleep 2
> +

If it's not too hard, it would be better to add an ovs-appctl command to
wait until the cuckoo distributor is ready.

In commit messages, when practical, it's better to refer to tests by
their name instead of number, or in addition to number, because the
numbers shift from one commit to the next.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [RFC PATCH 1/2] Adding DPDK configuration option to isolate rte-mempool allocation.

2017-11-03 Thread Ben Pfaff
On Wed, Nov 01, 2017 at 05:46:43PM +, Sugesh Chandran wrote:
> DPDK allocate memory regions at the time of vswitchd init. To run multiple
> primary instance of DPDK including OVS on a single platform, the memory map
> regions in the filesystem should be distinct.
> 
> The new configuration option let user to enable the memory isolation in need.
> By default, OVS uses default dpdk memory regions.
> 
> To isolate the memory regions, DPDK prefix the memory map files with user
> input string. This implementation uses the pid of vswitchd process as a memory
> map prefix, because its unique in the platform.
> 
> For eg: a vswitchd process with pid '12345' create memory map regions with
> prefix 'ovs-12345' in the filesystem.
> 
> The following configuration option is used to enable the feature and changing
> this value requires restarting the daemon.
> 
>  ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-isolate-mem=true
> 
> Signed-off-by: Sugesh Chandran 

I believe that this patch adds code to ovs-vswitchd to read
ovs-vswitchd's own pidfile.  I don't understand this.  Wouldn't it make
more sense to just call getpid()?

Thanks,

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


Re: [ovs-dev] [blp/ovs-reviews/raft9][PATCH] ovn-ctl: Support starting clustered OVN dbs

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 09:21:34PM +0530, nusid...@redhat.com wrote:
> From: Numan Siddique 
> 
> This patch adds the options to start clustered OVN db servers.
> To support this following options are added - '--db-nb-cluster-local-addr',
> '--db-nb-cluster-remote-addr', '--db-sb-cluster-local-addr' and
> '--db-sb-cluster-remote-addr'. If only '--db-(nb/sb)-cluster-local-addr' is 
> defined
> then clustered db is created (using ovsdb-tool create-cluster). If both are 
> defined,
> then the db is added to the cluster (using ovsdb-tool join-cluster)
> 
> Signed-off-by: Numan Siddique 
> ---
> 
> This patch is on top of Ben's ovs-revews git repo branch raft9.

Thanks a lot, I applied this to my raft9 branch.  I didn't review it in
detail, although that needs to happen before any merge to master.

Thanks again!

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


Re: [ovs-dev] [PATCH v2] lib: Move lib/poll-loop.h to include/openvswitch

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 01:53:53PM +0800, Xiao Liang wrote:
> Poll-loop is the core to implement main loop. It should be available in
> libopenvswitch.
> 
> Signed-off-by: Xiao Liang 

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


Re: [ovs-dev] [PATCH] meta-flow: Fix format in documentation.

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 10:32:57AM -0700, Yi-Hung Wei wrote:
> Signed-off-by: Yi-Hung Wei 

Thanks!  Applied to master and branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] actions in openflow rules

2017-11-03 Thread Ben Pfaff
On Thu, Nov 02, 2017 at 11:54:16PM +, Haitham Ghalwash wrote:
> I am a little bit confused when interpreting the action part for the 
> following rule,  I got the rule by initiating the "ovs-ofctl dump-flows" on 
> my mininet openflow switch.
> 
> 
> cookie=0x2ba5, duration=528.939s, table=0, n_packets=176, 
> n_bytes=33116, idle_age=0, priority=2,in_port=1 actions=output:4,output:2
> 
> 
> we have multiple action ports in a certain order, when checking the 
> "restconf/operational/opendaylight-inventory:nodes/" in the opendaylight 
> controller we can see each action with different order
> 
> "action": [
>   { "order": 0,"output-action": {
>"max-length": 65535,
> "output-node-connector": "2" }
>   {"order": 1, "output-action": {
> "max-length": 65535,
> "output-node-connector": "4" }
> }
> 
> 
> I am not sure how the packets hitting such entry will be forwarded, are they 
> replicated and send over both? are they load balanced over all ports?

OpenFlow actions are executed in the specified order, so these actions
will output the packet to port 4, then to port 2.  I can't speak for how
OpenDaylight orders or formats actions.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ofp-util: Update OpenFlow 1.6 port support to track latest proposal.

2017-11-03 Thread Ben Pfaff
On Thu, Nov 02, 2017 at 05:19:07PM -0700, Yi-Hung Wei wrote:
> On Tue, Oct 24, 2017 at 3:17 PM, Ben Pfaff  wrote:
> > This patch, from July, still applies and still needs a review.
> >
> > On Fri, Jul 14, 2017 at 12:51:43PM -0700, Ben Pfaff wrote:
> >> The latest updates to the OpenFlow 1.6 proposal removes the hw_addr_type
> >> fields from ofp_port and ofp_port_mod.  This commit updates the OVS
> >> prototype to match the updated proposal.
> >>
> >> ONF-JIRA: EXT-566
> >> Signed-off-by: Ben Pfaff 
> >> ---
> 
> Thanks for the patch. It looks good to me.
> 
> Acked-by: Yi-Hung Wei 

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


Re: [ovs-dev] [PATCH v2] ovn-northd.8: Fix wrong description

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 09:08:26AM +0800, wei wrote:
> Signed-off-by: wei 

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


[ovs-dev] [PATCH] meta-flow: Fix format in documentation.

2017-11-03 Thread Yi-Hung Wei
Signed-off-by: Yi-Hung Wei 
---
 lib/meta-flow.xml | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/meta-flow.xml b/lib/meta-flow.xml
index 065fb0335678..08ee0ece79b7 100644
--- a/lib/meta-flow.xml
+++ b/lib/meta-flow.xml
@@ -2643,7 +2643,7 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
   reflect the values from that initial non-committed non-related packet,
   and thus may be different from the actual packet headers, as the
   actual packet headers may be in reverse direction (for reply packets),
-  transformed by NAT (when \fBnat\fR option was applied to the
+  transformed by NAT (when nat option was applied to the
   connection), or be of different protocol (i.e., when an ICMP response
   is sent to an UDP packet).  In case of related connections, e.g., an
   FTP data connection, the original direction tuple contains the
@@ -2655,8 +2655,9 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
   The following fields are populated by the ct action, and require a
   match to a valid connection tracking state as a prerequisite, in
   addition to the IP or IPv6 ethertype match.  Examples of valid
-  connection tracking state matches include \fBct_state=+new\fR,
-  \fBct_state=+est\fR, \fBct_state=+rel\fR, and \fBct_state=+trk-inv\fR.
+  connection tracking state matches include ct_state=+new,
+  ct_state=+est, ct_state=+rel, and
+  ct_state=+trk-inv.
 
 
 
-- 
2.7.4

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


Re: [ovs-dev] [PATCH v10 0/4] Add Router Solicitation responder support and generate Neighbor Solicitation request for unknown

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 09:16:36AM +0530, Numan Siddique wrote:
> On Fri, Nov 3, 2017 at 2:10 AM, Ben Pfaff  wrote:
> 
> > On Thu, Nov 02, 2017 at 01:37:40PM -0700, Ben Pfaff wrote:
> > > Thank you for the patches!  They look good to me, so I will apply them
> > > to master soon.  I folded in a few minor changes to patch 2, which I'll
> > > mention in a reply to that patch.
> >
> > Oh, one more thing: I'd appreciate it if you would follow up with a
> > patch that adds an item to NEWS, to explain the new feature to end
> > users.
> >
> >
> Thanks Ben for the review and applying them. I submitted the patch for the
> NEWS
>  here - https://patchwork.ozlabs.org/patch/833636/

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


Re: [ovs-dev] [PATCH] NEWS: Add recently added OVN IPv6 features

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 09:13:16AM +0530, nusid...@redhat.com wrote:
> From: Numan Siddique 
> 
> OVN now supports sending IPv6 RA packet in response to the RS packet
> and resolves the unknown next hop MACs by generating a NS packet.
> 
> Mention this in the NEWS.
> 
> Signed-off-by: Numan Siddique 

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


Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Fix null pointer dereference on exit.

2017-11-03 Thread Jakub Sitnicki
On Thu, 2 Nov 2017 11:15:23 -0700
Ben Pfaff  wrote:

> > Forgot to ask - any chance it could be also applied back to branch-2.7?  
> 
> I backported to branch-2.8, but branch-2.7 doesn't have the code that
> causes this problem.

Thank you. I should have checked before asking. Will remember next time.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v2 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Jakub Sitnicki
On Fri, Nov 03, 2017 at 04:24 PM GMT, Mark Michelson wrote:
> Thanks for the reviews Jakub. I've added an in-line comment below.
> Otherwise consider that there is an implicit "Will do!" on all of your
> other suggestions.
>
> On Fri, Nov 3, 2017 at 11:04 AM Jakub Sitnicki  wrote:

[...]

>> > diff --git a/lib/packets.h b/lib/packets.h
>> > index 057935cbf..9d69b93d0 100644
>> > --- a/lib/packets.h
>> > +++ b/lib/packets.h
>> > @@ -976,6 +976,7 @@ BUILD_ASSERT_DECL(ND_PREFIX_OPT_LEN == sizeof(struct
>> ovs_nd_prefix_opt));
>> >
>> >  /* Neighbor Discovery option: MTU. */
>> >  #define ND_MTU_OPT_LEN 8
>> > +#define ND_MTU_DEFAULT 0
>> >  struct ovs_nd_mtu_opt {
>> >  uint8_t  type;  /* ND_OPT_MTU */
>> >  uint8_t  len;   /* Always 1. */
>> > @@ -1015,6 +1016,9 @@ BUILD_ASSERT_DECL(RA_MSG_LEN == sizeof(struct
>> ovs_ra_msg));
>> >  #define ND_RA_MANAGED_ADDRESS 0x80
>> >  #define ND_RA_OTHER_CONFIG0x40
>> >
>> > +#define ND_RA_MAX_INTERVAL_DEFAULT 600
>> > +#define ND_RA_MIN_INTERVAL_DEFAULT(max) (max) >= 9 ? (max) / 3 : (max)
>> * 3 / 4
>> > +
>>
>> I don't understand the formula. It generates a sequence that is not
>> always increasing but takes a dip when max == 9. What is the reasoning
>> behind it?
>>
>
> It's based on RFC 4861 section 6.2.1.
>
>   MinRtrAdvInterval
>  The minimum time allowed between sending
>  unsolicited multicast Router Advertisements from
>  the interface, in seconds.  MUST be no less than 3
>  seconds and no greater than .75 *
>  MaxRtrAdvInterval.
>
>  Default: 0.33 * MaxRtrAdvInterval If
>  MaxRtrAdvInterval >= 9 seconds; otherwise, the
>  Default is 0.75 * MaxRtrAdvInterval.
>
> Note that this is not the exact quote from the RFC. I have altered the
> default text to include the suggested change from Errata 3154. Does that
> explain the formula better?
>
> I can add the citation to the code so that it makes more sense for someone
> skimming the code.

OK, I see now where it came from. Thanks for explaining it.

Maybe a short reference will do?

/* RFC 4861 MinRtrAdvInterval, MaxRtrAdvInterval */

... so the reader has a hint where to look it up.

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


Re: [ovs-dev] [PATCH v2 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Numan Siddique
On Fri, Nov 3, 2017 at 9:54 PM, Mark Michelson  wrote:

> Thanks for the reviews Jakub. I've added an in-line comment below.
> Otherwise consider that there is an implicit "Will do!" on all of your
> other suggestions.
>
> On Fri, Nov 3, 2017 at 11:04 AM Jakub Sitnicki  wrote:
>
> > Hi again Mark,
> >
> > A batch of nit-picks/suggestions & a question that I've collected so far
> > when reading through this patch. Please apply as you see fit.
> >
> > On Thu, Nov 02, 2017 at 08:47 PM GMT, Mark Michelson wrote:
> > > This change adds three new options to the Northbound
> > > Logical_Router_Port's ipv6_ra_configs option:
> > >
> > > * send_periodic: If set to "true", then OVN will send periodic router
> > > advertisements out of this router port.
> > > * max_interval: The maximum amount of time to wait between sending
> > > periodic router advertisements.
> > > * min_interval: The minimum amount of time to wait between sending
> > > periodic router advertisements.
> > >
> > > When send_periodic is true, then IPv6 RA configs, as well as some layer
> > > 2 and layer 3 information about the router port, are copied to the
> > > southbound database. From there, ovn-controller can use this
> information
> > > to know when to send periodic RAs and what to send in them.
> > >
> > > Because periodic RAs originate from each ovn-controller, the new
> > > keep-local flag is set on the packet so that ports don't receive an
> > > overabundance of RAs.
> > >
> > > Signed-off-by: Mark Michelson 
> > > ---
> > >  lib/packets.h|   4 +
> > >  ovn/controller/pinctrl.c | 349
> > +++
> > >  ovn/northd/ovn-northd.c  |  65 +
> > >  ovn/ovn-nb.xml   |  19 +++
> > >  tests/ovn-northd.at  | 110 +++
> > >  tests/ovn.at | 150 
> > >  6 files changed, 697 insertions(+)
> > >
> > > diff --git a/lib/packets.h b/lib/packets.h
> > > index 057935cbf..9d69b93d0 100644
> > > --- a/lib/packets.h
> > > +++ b/lib/packets.h
> > > @@ -976,6 +976,7 @@ BUILD_ASSERT_DECL(ND_PREFIX_OPT_LEN ==
> sizeof(struct
> > ovs_nd_prefix_opt));
> > >
> > >  /* Neighbor Discovery option: MTU. */
> > >  #define ND_MTU_OPT_LEN 8
> > > +#define ND_MTU_DEFAULT 0
> > >  struct ovs_nd_mtu_opt {
> > >  uint8_t  type;  /* ND_OPT_MTU */
> > >  uint8_t  len;   /* Always 1. */
> > > @@ -1015,6 +1016,9 @@ BUILD_ASSERT_DECL(RA_MSG_LEN == sizeof(struct
> > ovs_ra_msg));
> > >  #define ND_RA_MANAGED_ADDRESS 0x80
> > >  #define ND_RA_OTHER_CONFIG0x40
> > >
> > > +#define ND_RA_MAX_INTERVAL_DEFAULT 600
> > > +#define ND_RA_MIN_INTERVAL_DEFAULT(max) (max) >= 9 ? (max) / 3 :
> (max)
> > * 3 / 4
> > > +
> >
> > I don't understand the formula. It generates a sequence that is not
> > always increasing but takes a dip when max == 9. What is the reasoning
> > behind it?
> >
>
> It's based on RFC 4861 section 6.2.1.
>
> It would be nice if you could mention RFC 4861 in the code comments.

Thanks
Numan


>   MinRtrAdvInterval
>  The minimum time allowed between sending
>  unsolicited multicast Router Advertisements from
>  the interface, in seconds.  MUST be no less than 3
>  seconds and no greater than .75 *
>  MaxRtrAdvInterval.
>
>  Default: 0.33 * MaxRtrAdvInterval If
>  MaxRtrAdvInterval >= 9 seconds; otherwise, the
>  Default is 0.75 * MaxRtrAdvInterval.
>
> Note that this is not the exact quote from the RFC. I have altered the
> default text to include the suggested change from Errata 3154. Does that
> explain the formula better?
>
> I can add the citation to the code so that it makes more sense for someone
> skimming the code.
>
>
> >
> > Also, you probably want to put the expression in parenthesis to avoid
> > surprises in evalution like: ND_RA_MIN_INTERVAL_DEFAULT(max)*1000.
> >
> > >  /*
> > >   * Use the same struct for MLD and MLD2, naming members as the defined
> > fields in
> > >   * in the corresponding version of the protocol, though they are
> > reserved in the
> > > diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> > > index 29b2dde0c..f97eba4d5 100644
> > > --- a/ovn/controller/pinctrl.c
> > > +++ b/ovn/controller/pinctrl.c
> > > @@ -48,6 +48,7 @@
> > >  #include "socket-util.h"
> > >  #include "timeval.h"
> > >  #include "vswitch-idl.h"
> > > +#include "lflow.h"
> > >
> > >  VLOG_DEFINE_THIS_MODULE(pinctrl);
> > >
> > > @@ -88,6 +89,11 @@ static void pinctrl_handle_put_nd_ra_opts(
> > >  static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
> > >   const struct match *md,
> > >   struct ofpbuf *userdata);
> > > +static void init_ipv6_ras(void);
> > > +static void destroy_ipv6_ras(void);
> > > +static void ipv6_ra_wait(void);
> > > +static void send_ipv6_ras(const struct controller_ctx *ct

[ovs-dev] Few issues in my raft testing

2017-11-03 Thread Numan Siddique
Hi Ben,

I have noticed a couple of issues when testing raft support in
ovsdb-server. I am testing from your ovs-reviews/raft9 repo.

1) As I had mentioned in the IRC meeting yesterday, when I pass the options
"--remote=db:OVN_Northbound,NB_Global,connections" to ovsdb-server, it is
failing with the error
"ovsdb-server: "db:OVN_Northbound,NB_Global,connections": no table named
NB_Global".

I see this issue when I freshly create the database file (ovsdb-tool
create-cluster ovnnb.db OVN_Northbound local_addr remote_addr" and start
ovsdb-server) and start the ovsdb-server.

This issue is not seen if the ovsdb-server has already connected to the
remote and the above option is passed in subsequent runs.


b) I am seeing an issue when I run  "ovn-nbctl ls-add sw2". It hangs.

I created a 2 node cluster - node 1 and node 2
 When I run "ovn-nbctl ls-add sw2" it hangs. Here are the steps
   1. On node 1 created a clustered db and started ovsdb-server
 (/usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
--db-nb-cluster-local-addr=tcp:192.168.121.91:6643
--db-sb-cluster-local-addr=tcp:192.168.121.91:6644)
   2. Created a logical switch "ovn-nbctl ls-add sw0"

   3. On node 2, started ovsdb-servers as
 /usr/share/openvswitch/scripts/ovn-ctl start_ovsdb
--db-nb-cluster-local-addr=tcp:192.168.121.87:6643
--db-sb-cluster-local-addr=tcp:192.168.121.87:6644
--db-nb-cluster-remote-addr=tcp:192.168.121.91:6643
--db-sb-cluster-remote-addr=tcp:192.168.121.91:6644

  4. "ovn-nbctl show" works fine. Ran "ovn-nbctl ls-add sw1" and it worked
fine.

  5. Stop ovsdb-server - /usr/share/openvswitch/scripts/ovn-ctl stop_ovsdb

  6. Start again and when I run "ovn-nbctl ls-add sw2" it hangs.
   You can find the logs of ovsdb-server for node 2 here -
https://paste.fedoraproject.org/paste/xp~8lxdoq52TO28NbGoQbg

   and node 1 here -
https://paste.fedoraproject.org/paste/~J4rG9H36GWWWav98N5KaQ


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


Re: [ovs-dev] [PATCH v2 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Mark Michelson
Thanks for the reviews Jakub. I've added an in-line comment below.
Otherwise consider that there is an implicit "Will do!" on all of your
other suggestions.

On Fri, Nov 3, 2017 at 11:04 AM Jakub Sitnicki  wrote:

> Hi again Mark,
>
> A batch of nit-picks/suggestions & a question that I've collected so far
> when reading through this patch. Please apply as you see fit.
>
> On Thu, Nov 02, 2017 at 08:47 PM GMT, Mark Michelson wrote:
> > This change adds three new options to the Northbound
> > Logical_Router_Port's ipv6_ra_configs option:
> >
> > * send_periodic: If set to "true", then OVN will send periodic router
> > advertisements out of this router port.
> > * max_interval: The maximum amount of time to wait between sending
> > periodic router advertisements.
> > * min_interval: The minimum amount of time to wait between sending
> > periodic router advertisements.
> >
> > When send_periodic is true, then IPv6 RA configs, as well as some layer
> > 2 and layer 3 information about the router port, are copied to the
> > southbound database. From there, ovn-controller can use this information
> > to know when to send periodic RAs and what to send in them.
> >
> > Because periodic RAs originate from each ovn-controller, the new
> > keep-local flag is set on the packet so that ports don't receive an
> > overabundance of RAs.
> >
> > Signed-off-by: Mark Michelson 
> > ---
> >  lib/packets.h|   4 +
> >  ovn/controller/pinctrl.c | 349
> +++
> >  ovn/northd/ovn-northd.c  |  65 +
> >  ovn/ovn-nb.xml   |  19 +++
> >  tests/ovn-northd.at  | 110 +++
> >  tests/ovn.at | 150 
> >  6 files changed, 697 insertions(+)
> >
> > diff --git a/lib/packets.h b/lib/packets.h
> > index 057935cbf..9d69b93d0 100644
> > --- a/lib/packets.h
> > +++ b/lib/packets.h
> > @@ -976,6 +976,7 @@ BUILD_ASSERT_DECL(ND_PREFIX_OPT_LEN == sizeof(struct
> ovs_nd_prefix_opt));
> >
> >  /* Neighbor Discovery option: MTU. */
> >  #define ND_MTU_OPT_LEN 8
> > +#define ND_MTU_DEFAULT 0
> >  struct ovs_nd_mtu_opt {
> >  uint8_t  type;  /* ND_OPT_MTU */
> >  uint8_t  len;   /* Always 1. */
> > @@ -1015,6 +1016,9 @@ BUILD_ASSERT_DECL(RA_MSG_LEN == sizeof(struct
> ovs_ra_msg));
> >  #define ND_RA_MANAGED_ADDRESS 0x80
> >  #define ND_RA_OTHER_CONFIG0x40
> >
> > +#define ND_RA_MAX_INTERVAL_DEFAULT 600
> > +#define ND_RA_MIN_INTERVAL_DEFAULT(max) (max) >= 9 ? (max) / 3 : (max)
> * 3 / 4
> > +
>
> I don't understand the formula. It generates a sequence that is not
> always increasing but takes a dip when max == 9. What is the reasoning
> behind it?
>

It's based on RFC 4861 section 6.2.1.

  MinRtrAdvInterval
 The minimum time allowed between sending
 unsolicited multicast Router Advertisements from
 the interface, in seconds.  MUST be no less than 3
 seconds and no greater than .75 *
 MaxRtrAdvInterval.

 Default: 0.33 * MaxRtrAdvInterval If
 MaxRtrAdvInterval >= 9 seconds; otherwise, the
 Default is 0.75 * MaxRtrAdvInterval.

Note that this is not the exact quote from the RFC. I have altered the
default text to include the suggested change from Errata 3154. Does that
explain the formula better?

I can add the citation to the code so that it makes more sense for someone
skimming the code.


>
> Also, you probably want to put the expression in parenthesis to avoid
> surprises in evalution like: ND_RA_MIN_INTERVAL_DEFAULT(max)*1000.
>
> >  /*
> >   * Use the same struct for MLD and MLD2, naming members as the defined
> fields in
> >   * in the corresponding version of the protocol, though they are
> reserved in the
> > diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> > index 29b2dde0c..f97eba4d5 100644
> > --- a/ovn/controller/pinctrl.c
> > +++ b/ovn/controller/pinctrl.c
> > @@ -48,6 +48,7 @@
> >  #include "socket-util.h"
> >  #include "timeval.h"
> >  #include "vswitch-idl.h"
> > +#include "lflow.h"
> >
> >  VLOG_DEFINE_THIS_MODULE(pinctrl);
> >
> > @@ -88,6 +89,11 @@ static void pinctrl_handle_put_nd_ra_opts(
> >  static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
> >   const struct match *md,
> >   struct ofpbuf *userdata);
> > +static void init_ipv6_ras(void);
> > +static void destroy_ipv6_ras(void);
> > +static void ipv6_ra_wait(void);
> > +static void send_ipv6_ras(const struct controller_ctx *ctx,
> > +struct hmap *local_datapaths);
> >
> >  COVERAGE_DEFINE(pinctrl_drop_put_mac_binding);
> >
> > @@ -98,6 +104,7 @@ pinctrl_init(void)
> >  conn_seq_no = 0;
> >  init_put_mac_bindings();
> >  init_send_garps();
> > +init_ipv6_ras();
> >  }
> >
> >  static ovs_be32
> > @@ -1083,8 +1090,348 @@ pinctrl_run(struct controller_ctx *ctx,
> >  run_put_mac_

Re: [ovs-dev] [PATCH v2 0/5] dpif-netdev: Cuckoo-Distributor implementation

2017-11-03 Thread Wang, Yipeng1
To make it easier for the code reviewers to build and test the patchset, a TREX 
profile that presents a very simple synthetic test case of random traffic with 
20 different IP src and 50K different IP dst is attached. It can be used 
together with the rule set we mentioned in cover letter to generate uniform 
distribution of hits among the 20 subtables. This synthetic traffic pattern  
represents the worst-case scenario for the current subtable ranking method.  We 
observe about 2x speedup vs. the original OvS in this case. Note that the 
patchset automatically detects if there is benefit to turn CD on or off to 
accommodate any traffic pattern, so when the subtable ranking works perfectly, 
CD will not be enabled and will not harm the performance.

One can change the dstip and srcip_cnt variables to generate different number 
of flows and subtable count scenarios.

 
import locale, sys, time
from signal import *

import stl_path
from trex_stl_lib.api import *

[tx_port, rx_port] = my_ports = [0, 1]
tx_ports = [tx_port]
rx_ports = [rx_port]

global c

# dst IP vary from 0.0.0.0 to 0.0.195.255 is about 50k flows.
# src IP vary from 1.0.0.0 to 20.0.0.0 is 20 flows.
# 50k * 20 is about 1M total flows
dstip = "0.0.195.255"
srcip_cnt = 20
size = 64

#create stream blocks. Each stream has one srcIP with various dstIP.
#There are in total of 20 different srcIP.
def make_streams():
streams = [
{"base_pkt":Ether()/IP(src="{}.0.0.0".format(i), tos=0x20)/UDP(),
 "vm":[

STLVmFlowVar(name="ip_dst",min_value="0.0.0.0",max_value=dstip,size=4,op="random"),
STLVmWrFlowVar(fv_name="ip_dst",pkt_offset="IP.dst"),
]
}
for i in range(1,srcip_cnt + 1)
]
return streams

if __name__ == "__main__":

c = STLClient(verbose_level = LoggerApi.VERBOSE_QUIET)
c.connect()

c.reset(ports = my_ports)
new_streams = make_streams()

for s in new_streams:
# 64 - 4 for FCS
pad = max(0, size - 4 - len(s["base_pkt"])) * 'x'
s["base_pkt"] = s["base_pkt"]/pad

pkts = [STLPktBuilder(pkt = s["base_pkt"], vm = s["vm"]) for s in 
new_streams]

#generate contiguous traffic. Each stream has equal bandwidth.
final_streams = [STLStream(packet = pkt, mode = STLTXCont(percentage = 
100.0/len(pkts))) for pkt in pkts]
c.add_streams(final_streams, ports=[tx_port])
c.set_port_attr(my_ports, promiscuous = True)

#start the traffic
c.start(ports = tx_ports)
#wait for 20 seconds
time.sleep(20)
#write rx pps to stdio
sys.stdout.write(str("RX PPS: 
")+str(int(c.get_stats(my_ports)[1]["rx_pps"])) + str("\n"))
#stop the traffic
c.stop(ports=my_ports)
c.disconnect()
c = None
 


> -Original Message-
> From: Wang, Yipeng1
> Sent: Tuesday, October 31, 2017 4:40 PM
> To: d...@openvswitch.org
> Cc: Wang, Yipeng1 ; Gobriel, Sameh
> ; Fischetti, Antonio
> ; db...@vmware.com;
> jan.scheur...@ericsson.com
> Subject: [PATCH v2 0/5] dpif-netdev: Cuckoo-Distributor implementation
> 
> The Datapath Classifier uses tuple space search for flow classification.
> The rules are arranged into a set of tuples/subtables (each with a
> distinct mask).  Each subtable is implemented as a hash table and lookup
> is done with flow keys formed by selecting the bits from the packet header
> based on each subtable's mask. Tuple space search will sequentially search
> each subtable until a match is found. With a large number of subtables, a
> sequential search of the subtables could consume a lot of CPU cycles. In
> a testbench with a uniform traffic pattern equally distributed across 20
> subtables, we measured that up to 65% of total execution time is attributed
> to the megaflow cache lookup.
> 
> This patch presents the idea of the two-layer hierarchical lookup, where a
> low overhead first level of indirection is accessed first, we call this
> level cuckoo distributor (CD). If a flow key has been inserted in the flow
> table the first level will indicate with high probability that which
> subtable to look into. A lookup is performed on the second level (the
> target subtable) to retrieve the result. If the key doesn’t have a match,
> then we revert back to the sequential search of subtables. The patch is
> partially inspired by earlier concepts proposed in "simTable"[1] and
> "Cuckoo Filter"[2], and DPDK's Cuckoo Hash implementation.
> 
> This patch can improve the already existing Subtable Ranking when traffic
> data has high entropy. Subtable Ranking helps minimize the number of
> traversed subtables when most of the traffic hit the same subtable.
> However, in the case of high entropy traffic such as traffic coming from
> a physical port, multiple subtables could be hit with a similar frequency.
> In this case the average subtable lookups per hit would be much greater
> than 1. In addition, CD can adapt

Re: [ovs-dev] [PATCH v2 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Jakub Sitnicki
Hi again Mark,

A batch of nit-picks/suggestions & a question that I've collected so far
when reading through this patch. Please apply as you see fit.

On Thu, Nov 02, 2017 at 08:47 PM GMT, Mark Michelson wrote:
> This change adds three new options to the Northbound
> Logical_Router_Port's ipv6_ra_configs option:
>
> * send_periodic: If set to "true", then OVN will send periodic router
> advertisements out of this router port.
> * max_interval: The maximum amount of time to wait between sending
> periodic router advertisements.
> * min_interval: The minimum amount of time to wait between sending
> periodic router advertisements.
>
> When send_periodic is true, then IPv6 RA configs, as well as some layer
> 2 and layer 3 information about the router port, are copied to the
> southbound database. From there, ovn-controller can use this information
> to know when to send periodic RAs and what to send in them.
>
> Because periodic RAs originate from each ovn-controller, the new
> keep-local flag is set on the packet so that ports don't receive an
> overabundance of RAs.
>
> Signed-off-by: Mark Michelson 
> ---
>  lib/packets.h|   4 +
>  ovn/controller/pinctrl.c | 349 
> +++
>  ovn/northd/ovn-northd.c  |  65 +
>  ovn/ovn-nb.xml   |  19 +++
>  tests/ovn-northd.at  | 110 +++
>  tests/ovn.at | 150 
>  6 files changed, 697 insertions(+)
>
> diff --git a/lib/packets.h b/lib/packets.h
> index 057935cbf..9d69b93d0 100644
> --- a/lib/packets.h
> +++ b/lib/packets.h
> @@ -976,6 +976,7 @@ BUILD_ASSERT_DECL(ND_PREFIX_OPT_LEN == sizeof(struct 
> ovs_nd_prefix_opt));
>
>  /* Neighbor Discovery option: MTU. */
>  #define ND_MTU_OPT_LEN 8
> +#define ND_MTU_DEFAULT 0
>  struct ovs_nd_mtu_opt {
>  uint8_t  type;  /* ND_OPT_MTU */
>  uint8_t  len;   /* Always 1. */
> @@ -1015,6 +1016,9 @@ BUILD_ASSERT_DECL(RA_MSG_LEN == sizeof(struct 
> ovs_ra_msg));
>  #define ND_RA_MANAGED_ADDRESS 0x80
>  #define ND_RA_OTHER_CONFIG0x40
>
> +#define ND_RA_MAX_INTERVAL_DEFAULT 600
> +#define ND_RA_MIN_INTERVAL_DEFAULT(max) (max) >= 9 ? (max) / 3 : (max) * 3 / 
> 4
> +

I don't understand the formula. It generates a sequence that is not
always increasing but takes a dip when max == 9. What is the reasoning
behind it?

Also, you probably want to put the expression in parenthesis to avoid
surprises in evalution like: ND_RA_MIN_INTERVAL_DEFAULT(max)*1000.

>  /*
>   * Use the same struct for MLD and MLD2, naming members as the defined 
> fields in
>   * in the corresponding version of the protocol, though they are reserved in 
> the
> diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> index 29b2dde0c..f97eba4d5 100644
> --- a/ovn/controller/pinctrl.c
> +++ b/ovn/controller/pinctrl.c
> @@ -48,6 +48,7 @@
>  #include "socket-util.h"
>  #include "timeval.h"
>  #include "vswitch-idl.h"
> +#include "lflow.h"
>
>  VLOG_DEFINE_THIS_MODULE(pinctrl);
>
> @@ -88,6 +89,11 @@ static void pinctrl_handle_put_nd_ra_opts(
>  static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
>   const struct match *md,
>   struct ofpbuf *userdata);
> +static void init_ipv6_ras(void);
> +static void destroy_ipv6_ras(void);
> +static void ipv6_ra_wait(void);
> +static void send_ipv6_ras(const struct controller_ctx *ctx,
> +struct hmap *local_datapaths);
>
>  COVERAGE_DEFINE(pinctrl_drop_put_mac_binding);
>
> @@ -98,6 +104,7 @@ pinctrl_init(void)
>  conn_seq_no = 0;
>  init_put_mac_bindings();
>  init_send_garps();
> +init_ipv6_ras();
>  }
>
>  static ovs_be32
> @@ -1083,8 +1090,348 @@ pinctrl_run(struct controller_ctx *ctx,
>  run_put_mac_bindings(ctx);
>  send_garp_run(ctx, br_int, chassis, chassis_index, local_datapaths,
>active_tunnels);
> +send_ipv6_ras(ctx, local_datapaths);
>  }
>
> +/* Table of ipv6_ra_state structures, keyed on logical port name */
> +static struct shash ipv6_ras;
> +
> +/* Next IPV6 RA in seconds. */
> +static long long int send_ipv6_ra_time;
> +
> +struct ipv6_network_prefix {
> +struct in6_addr addr;
> +unsigned int prefix_len;
> +};
> +
> +struct ipv6_ra_config {
> +time_t min_interval;
> +time_t max_interval;
> +struct eth_addr eth_src;
> +struct eth_addr eth_dst;
> +struct in6_addr ipv6_src;
> +struct in6_addr ipv6_dst;
> +ovs_be32 mtu;
> +uint8_t mo_flags;

Maybe annotate? For example /* Managed/Other RA flags */

> +uint8_t la_flags;

Maybe annotate? For example /* SLLAO flags */

> +struct ipv6_network_prefix *prefixes;
> +int n_prefixes;
> +};
> +
> +struct ipv6_ra_state {
> +long long int next_announce;
> +struct ipv6_ra_config *config;
> +int64_t port_key;
> +int64_t metadata;
> +bool deleteme;
> +};
> +
> +static void
> +init_ipv6_ras(void)
> +{
> +shash_init(&ipv6_ras);
> +send_ipv6_ra_time =

Re: [ovs-dev] [PATCH] rhel: Add support for "systemctl reload openvswitch"

2017-11-03 Thread Flavio Leitner
On Tue, 31 Oct 2017 12:11:32 +0100
Timothy Redaelli  wrote:

> The reload procedure will trigger a script that saves the flows and tlv
> maps (using ovs-save) then it restarts ovsdb-server, it stops ovs-vswitchd,
> it sets other_config:flow-restore-wait=true (to wait till flow restore is
> finished), it starts ovs-vswitchd, it restore the backupped flows/tlv
> maps and it removes other_config:flow-restore-wait=true (logic mostly ripped
> from ovs-ctl).
> 
> It uses systemctl with --job-mode=ignore-dependencies to restart ovsdb-server
> and stop and start ovs-vswitchd in order to avoid systemd to restart the other
> components due to dependencies (as explained in rhel/README.RHEL.rst).
> 
> Signed-off-by: Timothy Redaelli 
> ---
>  rhel/automake.mk |  1 +
>  rhel/openvswitch-fedora.spec.in  |  5 
>  rhel/usr_lib_systemd_system_openvswitch.service  |  2 +-
>  rhel/usr_lib_systemd_system_ovsdb-server.service |  1 -
>  rhel/usr_share_openvswitch_scripts_ovs-reload| 36 
> 
>  5 files changed, 43 insertions(+), 2 deletions(-)
>  create mode 100755 rhel/usr_share_openvswitch_scripts_ovs-reload
> 
> diff --git a/rhel/automake.mk b/rhel/automake.mk
> index 9336f0912..0955dceed 100644
> --- a/rhel/automake.mk
> +++ b/rhel/automake.mk
> @@ -24,6 +24,7 @@ EXTRA_DIST += \
>   rhel/openvswitch.spec.in \
>   rhel/openvswitch-fedora.spec \
>   rhel/openvswitch-fedora.spec.in \
> + rhel/usr_share_openvswitch_scripts_ovs-reload \
>   rhel/usr_share_openvswitch_scripts_sysconfig.template \
>   rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \
>   rhel/usr_lib_udev_rules.d_91-vfio.rules \
> diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
> index fb7d918c6..87bec39c9 100644
> --- a/rhel/openvswitch-fedora.spec.in
> +++ b/rhel/openvswitch-fedora.spec.in
> @@ -314,6 +314,10 @@ install -d -m 0755 
> $RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn
>  ln -s %{_datadir}/openvswitch/scripts/ovndb-servers.ocf \
>$RPM_BUILD_ROOT%{_prefix}/lib/ocf/resource.d/ovn/ovndb-servers
>  
> +install -p -D -m 0755 \
> +rhel/usr_share_openvswitch_scripts_ovs-reload \
> +$RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovs-reload
> +
>  # remove unpackaged files
>  rm -f $RPM_BUILD_ROOT%{_bindir}/ovs-parse-backtrace \
>  $RPM_BUILD_ROOT%{_sbindir}/ovs-vlan-bug-workaround \
> @@ -539,6 +543,7 @@ fi
>  %{_datadir}/openvswitch/scripts/ovs-save
>  %{_datadir}/openvswitch/scripts/ovs-vtep
>  %{_datadir}/openvswitch/scripts/ovs-ctl
> +%{_datadir}/openvswitch/scripts/ovs-reload
>  %config %{_datadir}/openvswitch/vswitch.ovsschema
>  %config %{_datadir}/openvswitch/vtep.ovsschema
>  %{_bindir}/ovs-appctl
> diff --git a/rhel/usr_lib_systemd_system_openvswitch.service 
> b/rhel/usr_lib_systemd_system_openvswitch.service
> index faca44b54..2cf29f0e9 100644
> --- a/rhel/usr_lib_systemd_system_openvswitch.service
> +++ b/rhel/usr_lib_systemd_system_openvswitch.service
> @@ -9,7 +9,7 @@ Requires=ovs-vswitchd.service
>  [Service]
>  Type=oneshot
>  ExecStart=/bin/true
> -ExecReload=/bin/true
> +ExecReload=/usr/share/openvswitch/scripts/ovs-reload
>  ExecStop=/bin/true
>  RemainAfterExit=yes
>  
> diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
> b/rhel/usr_lib_systemd_system_ovsdb-server.service
> index 5baac822d..234d39355 100644
> --- a/rhel/usr_lib_systemd_system_ovsdb-server.service
> +++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
> @@ -3,7 +3,6 @@ Description=Open vSwitch Database Unit
>  After=syslog.target network-pre.target
>  Before=network.target network.service
>  Wants=ovs-delete-transient-ports.service
> -ReloadPropagatedFrom=openvswitch.service
>  PartOf=openvswitch.service
>  
>  [Service]
> diff --git a/rhel/usr_share_openvswitch_scripts_ovs-reload 
> b/rhel/usr_share_openvswitch_scripts_ovs-reload
> new file mode 100755
> index 0..3ac1a46c6
> --- /dev/null
> +++ b/rhel/usr_share_openvswitch_scripts_ovs-reload
> @@ -0,0 +1,36 @@
> +#! /bin/sh
> +
> +# Copyright (c) 2017 Red Hat, Inc.
> +#
> +# Licensed under the Apache License, Version 2.0 (the "License");
> +# you may not use this file except in compliance with the License.
> +# You may obtain a copy of the License at:
> +#
> +# http://www.apache.org/licenses/LICENSE-2.0
> +#
> +# Unless required by applicable law or agreed to in writing, software
> +# distributed under the License is distributed on an "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +# See the License for the specific language governing permissions and
> +# limitations under the License.
> +
> +# Save flows
> +bridges=$(ovs-vsctl -- --real list-br)
> +flows=$(/usr/share/openvswitch/scripts/ovs-save save-flows $bridges)
> +
> +# Restart the database first, since a large database may take a
> +# while to load, and we want to minimize forwarding disruption.
> +systemctl -

[ovs-dev] [blp/ovs-reviews/raft9][PATCH] ovn-ctl: Support starting clustered OVN dbs

2017-11-03 Thread nusiddiq
From: Numan Siddique 

This patch adds the options to start clustered OVN db servers.
To support this following options are added - '--db-nb-cluster-local-addr',
'--db-nb-cluster-remote-addr', '--db-sb-cluster-local-addr' and
'--db-sb-cluster-remote-addr'. If only '--db-(nb/sb)-cluster-local-addr' is 
defined
then clustered db is created (using ovsdb-tool create-cluster). If both are 
defined,
then the db is added to the cluster (using ovsdb-tool join-cluster)

Signed-off-by: Numan Siddique 
---

This patch is on top of Ben's ovs-revews git repo branch raft9.

 ovn/utilities/ovn-ctl | 129 +-
 utilities/ovs-lib.in  |  47 ++
 2 files changed, 143 insertions(+), 33 deletions(-)

diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
index 3e247a1c6..45203219f 100755
--- a/ovn/utilities/ovn-ctl
+++ b/ovn/utilities/ovn-ctl
@@ -95,70 +95,120 @@ promote_ovnsb() {
 
 start_nb_ovsdb() {
 # Check and eventually start ovsdb-server for Northbound DB
-if ! pidfile_is_running $DB_NB_PID; then
+if pidfile_is_running $DB_NB_PID; then
+return
+fi
+
+mode="standalone"
+
+if test ! -z "$DB_NB_CLUSTER_LOCAL_ADDR"; then
+mode="cluster"
+elif test ! -z "$DB_NB_SYNC_FROM_ADDR"; then
+mode="active_passive"
+echo "$DB_NB_SYNC_FROM_PROTO:$DB_NB_SYNC_FROM_ADDR:\
+$DB_NB_SYNC_FROM_PORT" > $ovnnb_active_conf_file
+fi
+
+if test X$mode != "Xcluster"; then
 upgrade_db "$DB_NB_FILE" "$DB_NB_SCHEMA" 1>/dev/null 2>/dev/null
+else
+if test -z "$DB_NB_CLUSTER_REMOTE_ADDR"; then
+create_cluster "$DB_NB_FILE" "$DB_NB_SCHEMA" \
+"$DB_NB_CLUSTER_LOCAL_ADDR"
+else
+join_cluster "$DB_NB_FILE" "OVN_Northbound" \
+"$DB_NB_CLUSTER_LOCAL_ADDR" "$DB_NB_CLUSTER_REMOTE_ADDR"
+fi
+fi
 
-set ovsdb-server
+set ovsdb-server
+set "$@" --detach --monitor
+set "$@" $OVN_NB_LOG --log-file=$OVN_NB_LOGFILE
+set "$@" --remote=punix:$DB_NB_SOCK --pidfile=$DB_NB_PID
+set "$@" --unixctl=ovnnb_db.ctl
 
-set "$@" --detach --monitor
-set "$@" $OVN_NB_LOG --log-file=$OVN_NB_LOGFILE
-set "$@" --remote=punix:$DB_NB_SOCK --pidfile=$DB_NB_PID
+# TODO (numans): Remove this 'if' once we have the fix to
+# start ovsdb-server with the below options for the cluster db.
+if test X$mode != "Xcluster"; then
 set "$@" --remote=db:OVN_Northbound,NB_Global,connections
-set "$@" --unixctl=ovnnb_db.ctl
 set "$@" --private-key=db:OVN_Northbound,SSL,private_key
 set "$@" --certificate=db:OVN_Northbound,SSL,certificate
 set "$@" --ca-cert=db:OVN_Northbound,SSL,ca_cert
 set "$@" --ssl-protocols=db:OVN_Northbound,SSL,ssl_protocols
 set "$@" --ssl-ciphers=db:OVN_Northbound,SSL,ssl_ciphers
+fi
 
-if test X"$DB_NB_CREATE_INSECURE_REMOTE" = Xyes; then
-set "$@" --remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR
-fi
+if test X"$DB_NB_CREATE_INSECURE_REMOTE" = Xyes; then
+set "$@" --remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR
+fi
 
-if test ! -z "$DB_NB_SYNC_FROM_ADDR"; then
-echo 
"$DB_NB_SYNC_FROM_PROTO:$DB_NB_SYNC_FROM_ADDR:$DB_NB_SYNC_FROM_PORT" > 
$ovnnb_active_conf_file
-fi
+if test -e $ovnnb_active_conf_file; then
+set "$@" --sync-from=`cat $ovnnb_active_conf_file`
+fi
 
-if test -e $ovnnb_active_conf_file; then
-set "$@" --sync-from=`cat $ovnnb_active_conf_file`
-fi
+$@ $DB_NB_FILE
 
-$@ $DB_NB_FILE
+if test -z "$DB_NB_CLUSTER_REMOTE_ADDR"; then
 ovn-nbctl init
 fi
 }
 
 start_sb_ovsdb() {
-# Check and eventually start ovsdb-server for Southbound DB
-if ! pidfile_is_running $DB_SB_PID; then
+# Check and eventually start ovsdb-server for Northbound DB
+if pidfile_is_running $DB_SB_PID; then
+return
+fi
+
+mode="standalone"
+
+if test ! -z "$DB_SB_CLUSTER_LOCAL_ADDR"; then
+mode="cluster"
+elif test ! -z "$DB_SB_SYNC_FROM_ADDR"; then
+mode="active_passive"
+echo "$DB_SB_SYNC_FROM_PROTO:$DB_SB_SYNC_FROM_ADDR:\
+$DB_SB_SYNC_FROM_PORT" > $ovnsb_active_conf_file
+fi
+
+if test X$mode != "Xcluster"; then
 upgrade_db "$DB_SB_FILE" "$DB_SB_SCHEMA" 1>/dev/null 2>/dev/null
+else
+if test -z "$DB_SB_CLUSTER_REMOTE_ADDR"; then
+create_cluster "$DB_SB_FILE" "$DB_SB_SCHEMA" \
+"$DB_SB_CLUSTER_LOCAL_ADDR"
+else
+join_cluster "$DB_SB_FILE" "OVN_Southbound" \
+"$DB_SB_CLUSTER_LOCAL_ADDR" "$DB_SB_CLUSTER_REMOTE_ADDR"
+fi
+fi
 
-set ovsdb-server
+set ovsdb-server
+set "$@" --detach --monitor
+set "$@" $OVN_SB_LOG --log-file=$OVN_SB_LOGFILE
+set "$@" --remote=punix:$DB_SB_SOCK --pidfile=$DB_SB_PID
+set "$@" --unixctl=ovnsb_db.ctl
 
-set "$@" --detach --monitor
-set "$@" $OVN_SB_LOG --log-file=$OVN

Re: [ovs-dev] [PATCH v2 2/2] OVN: Add support for periodic router advertisements.

2017-11-03 Thread Jakub Sitnicki
Hi Mark,

On Thu,  2 Nov 2017 15:47:04 -0500
Mark Michelson  wrote:

> This change adds three new options to the Northbound
> Logical_Router_Port's ipv6_ra_configs option:
> 
> * send_periodic: If set to "true", then OVN will send periodic router
> advertisements out of this router port.
> * max_interval: The maximum amount of time to wait between sending
> periodic router advertisements.
> * min_interval: The minimum amount of time to wait between sending
> periodic router advertisements.
> 
> When send_periodic is true, then IPv6 RA configs, as well as some layer
> 2 and layer 3 information about the router port, are copied to the
> southbound database. From there, ovn-controller can use this information
> to know when to send periodic RAs and what to send in them.
> 
> Because periodic RAs originate from each ovn-controller, the new
> keep-local flag is set on the packet so that ports don't receive an
> overabundance of RAs.
> 
> Signed-off-by: Mark Michelson 
> ---

[...]

> +static struct ipv6_ra_config *
> +ipv6_ra_update_config(const struct sbrec_port_binding *pb)
> +{
> +struct ipv6_ra_config *config;
> +
> +config = xzalloc(sizeof *config);
> +
> +config->max_interval = smap_get_int(&pb->options, "ipv6_ra_max_interval",
> +ND_RA_MAX_INTERVAL_DEFAULT);
> +config->min_interval = smap_get_int(&pb->options, "ipv6_ra_min_interval",
> +ND_RA_MIN_INTERVAL_DEFAULT(config->max_interval));
> +config->mtu = htonl(smap_get_int(&pb->options, "ipv6_ra_mtu",
> +ND_MTU_DEFAULT));
> +config->la_flags = ND_PREFIX_ON_LINK;
> +
> +const char *address_mode = smap_get(&pb->options, 
> "ipv6_ra_address_mode");
> +if (!address_mode) {
> +VLOG_WARN("No address mode specified");
> +goto fail;
> +}
> +if (!strcmp(address_mode, "dhcpv6_stateless")) {
> +config->mo_flags = IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
> +} else if (!strcmp(address_mode, "dhcpv6_stateful")) {
> +config->mo_flags = IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
> +} else if (!strcmp(address_mode, "slaac")) {
> +config->la_flags |= ND_PREFIX_AUTONOMOUS_ADDRESS;
> +} else {
> +VLOG_WARN("Invalid address mode %s", address_mode);
> +goto fail;
> +}
> +
> +const char *prefixes = smap_get(&pb->options, "ipv6_ra_prefixes");
> +if (prefixes) {
> +char *prefixes_copy = xstrdup(prefixes);
> +char *prefix;
> +
> +/* Prefixes are in the format:
> + * addr/len, where
> + * addr is the network prefix
> + * and len is the prefix length
> + */
> +while ((prefix = strsep(&prefixes_copy, " "))) {
> +char *cidr;
> +
> +cidr = strchr(prefix, '/');
> +if (!cidr) {
> +VLOG_WARN("No prefix length on network prefix %s", prefix);
> +continue;
> +}
> +*cidr++ = '\0';
> +
> +unsigned int prefix_len;
> +prefix_len = atoi(cidr);
> +if (prefix_len == 0 || prefix_len > 128) {
> +VLOG_WARN("Invalid prefix length %u", prefix_len);
> +continue;
> +}
> +
> +struct in6_addr prefix_addr;
> +if (!ipv6_parse(prefix, &prefix_addr)) {
> +continue;
> +}
> +
> +config->n_prefixes++;
> +config->prefixes = xrealloc(config->prefixes,
> +config->n_prefixes * sizeof *config->prefixes);
> +
> +struct ipv6_network_prefix *network;
> +network = &config->prefixes[config->n_prefixes - 1];
> +network->addr = prefix_addr;
> +network->prefix_len = prefix_len;
> +}
> +free (prefixes_copy);
> +}

I think we could use ipv6_parse_cidr() for parsing the prefix.

[...]

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


Re: [ovs-dev] [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK

2017-11-03 Thread Jan Scheurich
Hi Darrel,

I have now been able to actually test the example pipelines I provided earlier. 
Turns out that the first one I sent was correct. Please note that it was not 
meant as realistic conntrack pipeline but just to demonstrate the misalignment 
between userspace and kernel conntrack and the conflict of both with the 
documentation.

The following pipeline is now tested:

ovs-ofctl add-flow br0 "table=0,priority=10,in_port=1,icmp 
actions=ct(table=1,zone=5000)"
ovs-ofctl add-flow br0 "table=0,priority=10,in_port=1,arp actions=output:2"
ovs-ofctl add-flow br0 "table=0,priority=10,in_port=2 actions=output:1"
ovs-ofctl add-flow br0 
"table=1,priority=10,in_port=1,ct_state=-new+est-rel-inv+trk actions=output:2"
ovs-ofctl add-flow br0 "table=1,priority=10,in_port=1,ip,ct_state=+new+trk 
actions=ct(commit,zone=5000),goto_table:2"
ovs-ofctl add-flow br0 
"table=2,priority=10,in_port=1,ct_state=-new+est-rel-inv+trk actions=output:2"

The ct(commit) action in table 1 commits a new connection entry, but the 
subsequent match in table 2 proves that the ct_state of the packet is still not 
EST despite the commit. This contradicts the statement in man ovs-fields: “est 
(0x02)  Part of an existing connection. Set to 1 if this is a committed 
connection.”

Consequently the userspace datapath drops the first ICMP packet:

root@ubuntu:~# ip netns exec ns1 ping -c1 192.168.10.20
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
--- 192.168.10.20 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@ubuntu:/opt/ovs# ovs-ofctl -Oopenflow13 dump-flows br0
cookie=0x0, duration=30.885s, table=0, n_packets=1, n_bytes=98, reset_counts 
priority=10,icmp,in_port="br0-ns1" actions=ct(table=1,zone=5000)
cookie=0x0, duration=30.848s, table=0, n_packets=0, n_bytes=0, reset_counts 
priority=10,arp,in_port="br0-ns1" actions=output:"br0-ns2"
cookie=0x0, duration=30.815s, table=0, n_packets=0, n_bytes=0, reset_counts 
priority=10,in_port="br0-ns2" actions=output:"br0-ns1"
cookie=0x0, duration=30.783s, table=1, n_packets=0, n_bytes=0, reset_counts 
priority=10,ct_state=-new+est-rel-inv+trk,in_port="br0-ns1" 
actions=output:"br0-ns2"
cookie=0x0, duration=30.746s, table=1, n_packets=1, n_bytes=98, reset_counts 
priority=10,ct_state=+new+trk,ip,in_port="br0-ns1" 
actions=ct(commit,zone=5000),resubmit(,2)
cookie=0x0, duration=30.712s, table=2, n_packets=0, n_bytes=0, reset_counts 
priority=10,ct_state=-new+est-rel-inv+trk,in_port="br0-ns1" 
actions=output:"br0-ns2"

root@ubuntu:/opt/ovs# ovs-appctl dpctl/dump-flows
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0806), packets:0, 
bytes:0, used:never, actions:3
recirc_id(0),in_port(3),packet_type(ns=0,id=0),eth_type(0x0806), packets:0, 
bytes:0, used:never, actions:2
ct_state(+new-est-rel-inv+trk),recirc_id(0x2),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
 packets:0, bytes:0, used:never, actions:ct(commit,zone=5000)
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=1,frag=no),
 packets:0, bytes:0, used:never, actions:ct(zone=5000),recirc(0x2)

root@ubuntu:/opt/ovs# ovs-appctl dpctl/dump-conntrack
icmp,orig=(src=192.168.10.10,dst=192.168.10.20,id=20697,type=8,code=0),reply=(src=192.168.10.20,dst=192.168.10.10,id=20697,type=0,code=0),zone=5000

But when I send two ICMP packets in a row, the second packet hits the 
connection entry committed by the first dropped packet and goes through:

root@ubuntu:~# ip netns exec ns1 ping -c2 192.168.10.20
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
64 bytes from 192.168.10.20: icmp_seq=2 ttl=64 time=1.87 ms
--- 192.168.10.20 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1006ms
rtt min/avg/max/mdev = 1.874/1.874/1.874/0.000 ms

root@ubuntu:/opt/ovs# ovs-ofctl -Oopenflow13 dump-flows br0
cookie=0x0, duration=40.727s, table=0, n_packets=2, n_bytes=196, reset_counts 
priority=10,icmp,in_port="br0-ns1" actions=ct(table=1,zone=5000)
cookie=0x0, duration=40.696s, table=0, n_packets=1, n_bytes=42, reset_counts 
priority=10,arp,in_port="br0-ns1" actions=output:"br0-ns2"
cookie=0x0, duration=40.667s, table=0, n_packets=2, n_bytes=140, reset_counts 
priority=10,in_port="br0-ns2" actions=output:"br0-ns1"
cookie=0x0, duration=40.631s, table=1, n_packets=1, n_bytes=98, reset_counts 
priority=10,ct_state=-new+est-rel-inv+trk,in_port="br0-ns1" 
actions=output:"br0-ns2"
cookie=0x0, duration=40.602s, table=1, n_packets=1, n_bytes=98, reset_counts 
priority=10,ct_state=+new+trk,ip,in_port="br0-ns1" 
actions=ct(commit,zone=5000),resubmit(,2)
cookie=0x0, duration=40.566s, table=2, n_packets=0, n_bytes=0, reset_counts 
priority=10,ct_state=-new+est-rel-inv+trk,in_port="br0-ns1" 
actions=output:"br0-ns2"

root@ubuntu:/opt/ovs# ovs-appctl dpctl/dump-flows
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0806), packets:0, 
bytes:0, used:never, actions:3
recirc_id(0),in_port(3),packet_type(ns=0,id=0),eth_type(0x0806), packets:0, 
byt