Re: [ovs-dev] [BUG] upcall handler thread crash

2017-02-05 Thread wangyunjian 
My ovs version is 
openvswitch-2.5.0(http://openvswitch.org/releases/openvswitch-2.5.0.tar.gz). 
I had modified the code as follows and getted other crash. Do it need a lock to 
protect the operations
of mbridge->mbundles hmap(xbridge->xport hmap) between ovs-vswichd thread and 
the upcall handler(revalidator) thread?

413 static struct mbundle *
414 mbundle_lookup(const struct mbridge *mbridge, struct ofbundle *ofbundle)
415 {
416 struct mbundle *mbundle;
417 
418 HMAP_FOR_EACH_IN_BUCKET (mbundle, hmap_node, hash_pointer(ofbundle, 0),
419  >mbundles) {
420 xsleep(2);  
   //only add xsleep(2)
421 if (mbundle->ofbundle == ofbundle) {
422 return mbundle;
423 }
424 }
425 return NULL;
426 }
427 

Call Trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fadfefd1700 (LWP 25029)]
mbundle_lookup (mbridge=, ofbundle=0x7fae03a55210) at 
ofproto/ofproto-dpif-mirror.c:421
421 if (mbundle->ofbundle == ofbundle) {
(gdb) bt
#0  mbundle_lookup (mbridge=, ofbundle=0x7fae03a55210) at 
ofproto/ofproto-dpif-mirror.c:421
#1  0x7fae029ec519 in mirror_bundle_out (mbridge=, 
ofbundle=) at ofproto/ofproto-dpif-mirror.c:183
#2  0x7fae029fba61 in xbundle_mirror_out (xbridge=, 
xbundle=0x7fae03a4e910) at ofproto/ofproto-dpif-xlate.c:1524
#3  xlate_normal (ctx=0x7fadfef94420) at ofproto/ofproto-dpif-xlate.c:2360
#4  xlate_output_action (ctx=ctx@entry=0x7fadfef94420, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto-dpif-xlate.c:3829
#5  0x7fae029f854f in do_xlate_actions 
(ofpacts=ofpacts@entry=0x7fade800e5a8, ofpacts_len=ofpacts_len@entry=8, 
ctx=ctx@entry=0x7fadfef94420) at ofproto/ofproto-dpif-xlate.c:4384
#6  0x7fae029fd6ec in xlate_actions (xin=xin@entry=0x7fadfef955c0, 
xout=xout@entry=0x7fadfefb3178) at ofproto/ofproto-dpif-xlate.c:5272
#7  0x7fae029f16f6 in upcall_xlate (wc=0x7fadfefb31d0, 
odp_actions=0x7fadfefb3190, upcall=0x7fadfefb3120, udpif=0x7fae03a81040) at 
ofproto/ofproto-dpif-upcall.c:1068
#8  process_upcall (udpif=udpif@entry=0x7fae03a81040, 
upcall=upcall@entry=0x7fadfefb3120, 
odp_actions=odp_actions@entry=0x7fadfefb3190, wc=wc@entry=0x7fadfefb31d0) at 
ofproto/ofproto-dpif-upcall.c:1206
#9  0x7fae029f3960 in recv_upcalls (handler=0x7fae03a4f5c8, 
handler=0x7fae03a4f5c8) at ofproto/ofproto-dpif-upcall.c:778
#10 0x7fae029f3e1c in udpif_upcall_handler (arg=0x7fae03a4f5c8) at 
ofproto/ofproto-dpif-upcall.c:696
#11 0x7fae02a7e596 in ovsthread_wrapper (aux_=) at 
lib/ovs-thread.c:340
#12 0x7fae01d14dc5 in start_thread () from /usr/lib64/libpthread.so.0
#13 0x7fae0132271d in clone () from /usr/lib64/libc.so.6
(gdb) p mbundle
$1 = (struct mbundle *) 0x

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fadfefd1700 (LWP 3570)]
0x7fae029f68a0 in get_ofp_port (xbridge=xbridge@entry=0x7fae03a81680, 
ofp_port=ofp_port@entry=1) at ofproto/ofproto-dpif-xlate.c:1400
1400if (xport->ofp_port == ofp_port) {
(gdb) bt
#0  0x7fae029f68a0 in get_ofp_port (xbridge=xbridge@entry=0x7fae03a81680, 
ofp_port=ofp_port@entry=1) at ofproto/ofproto-dpif-xlate.c:1400
#1  0x7fae029f692f in lookup_input_bundle (xbridge=0x7fae03a81680, 
in_port=1, warn=, in_xportp=in_xportp@entry=0x7fadfef93e90) at 
ofproto/ofproto-dpif-xlate.c:1550
#2  0x7fae029fba23 in xlate_normal (ctx=0x7fadfef94420) at 
ofproto/ofproto-dpif-xlate.c:2339
#3  xlate_output_action (ctx=ctx@entry=0x7fadfef94420, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto-dpif-xlate.c:3829
#4  0x7fae029f854f in do_xlate_actions 
(ofpacts=ofpacts@entry=0x7fae03a7f0a8, ofpacts_len=ofpacts_len@entry=8, 
ctx=ctx@entry=0x7fadfef94420) at ofproto/ofproto-dpif-xlate.c:4384
#5  0x7fae029fd6ec in xlate_actions (xin=xin@entry=0x7fadfef955c0, 
xout=xout@entry=0x7fadfefb3178) at ofproto/ofproto-dpif-xlate.c:5272
#6  0x7fae029f16f6 in upcall_xlate (wc=0x7fadfefb31d0, 
odp_actions=0x7fadfefb3190, upcall=0x7fadfefb3120, udpif=0x7fae03a4fb60) at 
ofproto/ofproto-dpif-upcall.c:1068
#7  process_upcall (udpif=udpif@entry=0x7fae03a4fb60, 
upcall=upcall@entry=0x7fadfefb3120, 
odp_actions=odp_actions@entry=0x7fadfefb3190, wc=wc@entry=0x7fadfefb31d0) at 
ofproto/ofproto-dpif-upcall.c:1206
#8  0x7fae029f3960 in recv_upcalls (handler=0x7fae03a7e7b8, 
handler=0x7fae03a7e7b8) at ofproto/ofproto-dpif-upcall.c:778
#9  0x7fae029f3e1c in udpif_upcall_handler (arg=0x7fae03a7e7b8) at 
ofproto/ofproto-dpif-upcall.c:696
#10 0x7fae02a7e596 in ovsthread_wrapper (aux_=) at 
lib/ovs-thread.c:340
#11 0x7fae01d14dc5 in start_thread () from /usr/lib64/libpthread.so.0
#12 0x7fae0132271d in clone () from /usr/lib64/libc.so.6
(gdb) p xport
$1 = (struct xport *) 0x19

> From: nickcooper-zhangtonghao

Re: [ovs-dev] [urgent] is there anyway to enable multi-vlan for one vm upon ovs ?

2017-02-05 Thread Ben Pfaff 
I don't think it normally makes sense to have IP addresses on the same
subnet on different VLANs.  If you do that, then how would the kernel
know, when it sends a packet to that subnet, which VLAN to use?

On Mon, Feb 06, 2017 at 10:17:31AM +0800, xiucai wrote:
> thanks a lot.
> i am very sorry about my delay, because i have take the Chinese spring 
> festival holidays :)
> 
> 
> in SVM, i had configured vlan as below:
>   modprobe 8021q
>   vconfig add eth0 2
>   vconfig add eth0 3
>   # add ifcfg-eth0.2/ifcfg-eth0.3 to /etc/sysconfig/network-scripts/ and 
> modify them.
>   systemctl restart network
>   # eth0/192.168.111.1 eth0.2@eth0/192.168.111.102 
> eth0.3@eth0/192.168.111.103 will appear.
> 
> 
> but, it still does not work :(
> 
> 
> so, could you give me details of "how to enable multi-vlan for one vm upon 
> openvswitch" :)
> 
> 
> regards!
> 
> 
> -- Original --
> From:  "Ben Pfaff";;
> Date:  Tue, Jan 24, 2017 00:21 AM
> To:  "xiucai"; 
> Cc:  "ovs-dev"; 
> Subject:  Re: [ovs-dev] [urgent] is there anyway to enable multi-vlan for 
> onvm upon ovs ?
> 
> 
> 
> On Sun, Jan 22, 2017 at 05:18:48PM +0800, xiucai wrote:
> > hi,
> > everyone :)
> > 
> > 
> > in my case, there is one vm for storage sharing, we name it SVM, and 
> > several VMs as testing client.
> > for historic reasons, i can not modify the network which uses vlan upon 
> > ovs.
> > 
> > 
> > the SVM is corresponding to vnet0, make it as trunk for tag-2 and tag-3;
> > the VM1 is corresponding to vnet2/tag-2 and the VM2 is corresponding to 
> > vnet4/tag-3.
> > i wanna all VMx can connect to SVM, but VMx can not communicate with 
> > each other!
> > 
> > 
> > ==configurations==
> > SVM's eth0: 192.168.1.1 static 52:54:01:CB:35:C4
> > VM1's eth0: 192.168.1.2 static 52:54:02:CB:35:C4
> > VM2's eth0: 192.168.1.3 static 52:54:03:CB:35:C4
> > 
> > 
> > Bridge "br1"
> > Port "vnet4"
> > tag: 3
> > Interface "vnet4"
> > Port "vnet0"
> > trunks: [2, 3]
> > Interface "vnet0"
> > Port "vnet2"
> > tag: 2
> > Interface "vnet2"
> > Port "br1"
> > Interface "br1"
> > type: internal
> > ovs_version: "2.5.0"
> > =
> > 
> > 
> > but it does not work :(
> > they can not ping through each other!
> > 
> > 
> > i use tcpdump to monitor eth0 on SVM, and ping SVM from VM1, it said 
> > "ARP Request who-has SVM-IP to tell VM1-IP".
> > and i use arp to add entry for each other, then it only said "VM1-IP > 
> > SVM-IP: ICMP echo request, id , seq x, length xx", but no "reply".
> > 
> > 
> > i have got no idea about this case, i do not know i have mistaken the 
> > concept of trunk on ovs or my config is wrong :(
> 
> Does your VM connected to vnet0 understand VLAN trunks?  Do you have
> VLAN interfaces configured there?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 08/10] windows: return NULL in xreadlink

2017-02-05 Thread Alin Serdean 
readlink does not exist on Windows.

While we could skip the function all togheter on Windows, we may add
support for it later on. For the moment return change errno to ENOENT
and return NULL.

FYI:
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#kBeZetM7P1dorllZ.97
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx

Signed-off-by: Alin Gabriel Serdean 
---
 lib/util.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/util.c b/lib/util.c
index 1c06ce0..5660ab5 100644
--- a/lib/util.c
+++ b/lib/util.c
@@ -980,6 +980,10 @@ abs_file_name(const char *dir, const char *file_name)
 static char *
 xreadlink(const char *filename)
 {
+#ifdef _WIN32
+errno = ENOENT;
+return NULL;
+#else
 size_t size;
 
 for (size = 64; ; size *= 2) {
@@ -998,6 +1002,7 @@ xreadlink(const char *filename)
 return NULL;
 }
 }
+#endif
 }
 
 /* Returns a version of 'filename' with symlinks in the final component
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 09/10] use portable getpagesize() in system-stats

2017-02-05 Thread Alin Serdean 
Use the intended portable function defined above "get_page_size()" not
"getpagesize()".

Signed-off-by: Alin Gabriel Serdean 
---
 vswitchd/system-stats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vswitchd/system-stats.c b/vswitchd/system-stats.c
index 49e5419..553b8fc 100644
--- a/vswitchd/system-stats.c
+++ b/vswitchd/system-stats.c
@@ -326,7 +326,7 @@ get_raw_process_info(pid_t pid, struct raw_process_info 
*raw)
 start_msec = get_boot_time() + ticks_to_ms(start_time);
 
 raw->vsz = vsize / 1024;
-raw->rss = rss * (getpagesize() / 1024);
+raw->rss = rss * (get_page_size() / 1024);
 raw->uptime = time_wall_msec() - start_msec;
 raw->cputime = ticks_to_ms(utime + stime);
 raw->ppid = ppid;
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 10/10] build-windows: cccl fail compilation on Wimplicit-function-declaration

2017-02-05 Thread Alin Serdean 
Gcc compiler argument -Wall contains -Wimplicit-function-declaration which
gives warnings when a function is used before declared.
Map VStudio compiler error C4013 to it.
More info on C4013:
https://msdn.microsoft.com/en-us/library/d3ct4kz9.aspx

At the moment we cannot switch to the equivalent -Werror because we need
to solve other warnings.

As a temporary solution issue an error when this warning is triggered.
This will help development on the Windows side.

Suggested-by: Ben Pfaff 
Signed-off-by: Alin Gabriel Serdean 
---
 build-aux/cccl | 8 
 1 file changed, 8 insertions(+)

diff --git a/build-aux/cccl b/build-aux/cccl
index 93f9c50..e2426fb 100644
--- a/build-aux/cccl
+++ b/build-aux/cccl
@@ -144,6 +144,14 @@ EOF
 #ignore pedantic
 ;;
 
+-Wall)
+# not all warnings are implemented
+# the following is equivalent to
+# Wimplicit-function-declaration but we will issue a compiler
+# error
+clopt="$clopt ${slash}we4013"
+;;
+
 -W*)
 #ignore warnings
 ;;
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 05/10] windows: fix calls in netlink-socket

2017-02-05 Thread Alin Serdean 
Add nl_sock_transact forward declaration, since it is used before
being on implemented. This applies only on Windows.

Move nl_sock_subscribe_packet__ function before it is used.

It makes more sense to move it rather than adding a forward declaration
since it is used by the two functions defined above it.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/netlink-socket.c | 50 ++
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/lib/netlink-socket.c b/lib/netlink-socket.c
index e45914c..f4c6fd9 100644
--- a/lib/netlink-socket.c
+++ b/lib/netlink-socket.c
@@ -60,6 +60,8 @@ static void log_nlmsg(const char *function, int error,
 #ifdef _WIN32
 static int get_sock_pid_from_kernel(struct nl_sock *sock);
 static int set_sock_property(struct nl_sock *sock);
+static int nl_sock_transact(struct nl_sock *sock, const struct ofpbuf *request,
+struct ofpbuf **replyp);
 #endif
 
 /* Netlink sockets. */
@@ -425,6 +427,30 @@ nl_sock_join_mcgroup(struct nl_sock *sock, unsigned int 
multicast_group)
 
 #ifdef _WIN32
 int
+nl_sock_subscribe_packet__(struct nl_sock *sock, bool subscribe)
+{
+struct ofpbuf request;
+uint64_t request_stub[128];
+struct ovs_header *ovs_header;
+struct nlmsghdr *nlmsg;
+int error;
+
+ofpbuf_use_stub(, request_stub, sizeof request_stub);
+nl_msg_put_genlmsghdr(, 0, OVS_WIN_NL_CTRL_FAMILY_ID, 0,
+  OVS_CTRL_CMD_PACKET_SUBSCRIBE_REQ,
+  OVS_WIN_CONTROL_VERSION);
+
+ovs_header = ofpbuf_put_uninit(, sizeof *ovs_header);
+ovs_header->dp_ifindex = 0;
+nl_msg_put_u8(, OVS_NL_ATTR_PACKET_SUBSCRIBE, subscribe ? 1 : 0);
+nl_msg_put_u32(, OVS_NL_ATTR_PACKET_PID, sock->pid);
+
+error = nl_sock_send(sock, , true);
+ofpbuf_uninit();
+return error;
+}
+
+int
 nl_sock_subscribe_packets(struct nl_sock *sock)
 {
 int error;
@@ -459,30 +485,6 @@ nl_sock_unsubscribe_packets(struct nl_sock *sock)
 sock->read_ioctl = OVS_IOCTL_READ;
 return 0;
 }
-
-int
-nl_sock_subscribe_packet__(struct nl_sock *sock, bool subscribe)
-{
-struct ofpbuf request;
-uint64_t request_stub[128];
-struct ovs_header *ovs_header;
-struct nlmsghdr *nlmsg;
-int error;
-
-ofpbuf_use_stub(, request_stub, sizeof request_stub);
-nl_msg_put_genlmsghdr(, 0, OVS_WIN_NL_CTRL_FAMILY_ID, 0,
-  OVS_CTRL_CMD_PACKET_SUBSCRIBE_REQ,
-  OVS_WIN_CONTROL_VERSION);
-
-ovs_header = ofpbuf_put_uninit(, sizeof *ovs_header);
-ovs_header->dp_ifindex = 0;
-nl_msg_put_u8(, OVS_NL_ATTR_PACKET_SUBSCRIBE, subscribe ? 1 : 0);
-nl_msg_put_u32(, OVS_NL_ATTR_PACKET_PID, sock->pid);
-
-error = nl_sock_send(sock, , true);
-ofpbuf_uninit();
-return error;
-}
 #endif
 
 /* Tries to make 'sock' stop listening to 'multicast_group'.  Returns 0 if
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 06/10] windows: add function definition to poll-loop.h

2017-02-05 Thread Alin Serdean 
poll_wevent_wait_at is used in the #define but the function definition
is missing.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/poll-loop.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/poll-loop.h b/lib/poll-loop.h
index 01e1aa8..84082f0 100644
--- a/lib/poll-loop.h
+++ b/lib/poll-loop.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2009, 2010, 2011, 2013 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2011, 2013, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -54,6 +54,7 @@ void poll_fd_wait_at(int fd, short int events, const char 
*where);
 #define poll_fd_wait(fd, events) poll_fd_wait_at(fd, events, 
OVS_SOURCE_LOCATOR)
 
 #ifdef _WIN32
+void poll_wevent_wait_at(HANDLE wevent, const char *where);
 #define poll_wevent_wait(wevent) poll_wevent_wait_at(wevent, 
OVS_SOURCE_LOCATOR)
 #endif /* _WIN32 */
 
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 03/10] windows: add includes to daemon-windows

2017-02-05 Thread Alin Serdean 
Add fatal-signal.h include since it uses: fatal_signal_atexit_handler
and fatal_signal_add_hook

Use the defined getpid() function and also include  since
it is defined in include/windows/unistd.h .

Signed-off-by: Alin Gabriel Serdean 
---
 lib/daemon-windows.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
index 7e2e9da..ccf4297 100644
--- a/lib/daemon-windows.c
+++ b/lib/daemon-windows.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 Nicira, Inc.
+ * Copyright (c) 2014, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -20,7 +20,9 @@
 #include 
 #include 
 #include 
+#include 
 #include "dirs.h"
+#include "fatal-signal.h"
 #include "ovs-thread.h"
 #include "poll-loop.h"
 #include "openvswitch/vlog.h"
@@ -476,7 +478,7 @@ make_pidfile(void)
 
 fatal_signal_add_hook(unlink_pidfile, NULL, NULL, true);
 
-fprintf(filep_pidfile, "%d\n", _getpid());
+fprintf(filep_pidfile, "%d\n", getpid());
 if (fflush(filep_pidfile) == EOF) {
 VLOG_FATAL("Failed to write into the pidfile %s", pidfile);
 }
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 07/10] windows: add include to stream-windows.c

2017-02-05 Thread Alin Serdean 
fatal_signal_unlink_file_now is used but the header for it is missing in
the include section.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/stream-windows.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/stream-windows.c b/lib/stream-windows.c
index 1950014..44b88bf 100644
--- a/lib/stream-windows.c
+++ b/lib/stream-windows.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2016 Cloudbase Solutions Srl
+ * Copyright (c) 2016, 2017 Cloudbase Solutions Srl
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -22,6 +22,7 @@
 #include 
 #include "poll-loop.h"
 #include "dirs.h"
+#include "fatal-signal.h"
 #include "util.h"
 #include "stream-provider.h"
 #include "openvswitch/vlog.h"
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 02/10] windows: add definition of getpid and getcwd

2017-02-05 Thread Alin Serdean 
getcwd - is used in lib/util.c. getcwd is deprecated on Windows but has
_getcwd which is defined in :
https://msdn.microsoft.com/en-us/library/sf98bd4y(v=vs.120).aspx

getpid - is used in several files (i.e. lib/vlog.c). getpid
is also and deprecated and _getpid should be used:
https://msdn.microsoft.com/en-us/library/t2y34y40(v=vs.120).aspx
The problem using _getpid is that the definition is in .
A file called process.h also exists in the lib folder. This will mess up
includes.
An option would be to use a wrapper like we use for lib/string.h(.in) but
that would mean to also add it to the automake chain.
A simple solution would be to map it to GetCurrentProcessId
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683180(v=vs.85).aspx
The disadvantage is the type but Windows recycles pids so in theory
it should be ok.

Signed-off-by: Alin Gabriel Serdean 
---
 include/windows/unistd.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/windows/unistd.h b/include/windows/unistd.h
index 8629f7e..3f92616 100644
--- a/include/windows/unistd.h
+++ b/include/windows/unistd.h
@@ -18,8 +18,11 @@
 
 #define WIN32_LEAN_AND_MEAN
 #include 
+#include 
 
 #define fsync _commit
+#define getpid GetCurrentProcessId
+#define getcwd _getcwd
 
 /* Standard file descriptors.  */
 #define STDIN_FILENO0   /* Standard input.  */
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 00/10] Implicit function declarations on Windows

2017-02-05 Thread Alin Serdean 
This series fixes all current errors when Wimplicit-function-declaration
(C4013) is triggered.

This is a part of the bigger plan to map all the GCC compiler flags to
their cl (Visual Studio compiler) equivalent.

For the original discussion please view:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328450.html

Alin Serdean (10):
  windows: Add definition of getrusage
  windows: add definition of getpid and getcwd
  windows: add includes to daemon-windows
  windows: add forward declaration to dpif-netlink
  windows: fix calls in netlink-socket
  windows: add function definition to poll-loop.h
  windows: add include to stream-windows.c
  windows: return NULL in xreadlink
  use portable getpagesize() in system-stats
  build-windows: cccl fail compilation on Wimplicit-function-declaration

 build-aux/cccl |  8 +++
 include/windows/sys/resource.h |  4 +++-
 include/windows/unistd.h   |  3 +++
 lib/daemon-windows.c   |  6 +++--
 lib/dpif-netlink.c |  3 +++
 lib/netlink-socket.c   | 50 ++
 lib/poll-loop.h|  3 ++-
 lib/stream-windows.c   |  3 ++-
 lib/util.c |  5 +
 vswitchd/system-stats.c|  2 +-
 10 files changed, 57 insertions(+), 30 deletions(-)

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

[ovs-dev] [PATCH 01/10] windows: Add definition of getrusage

2017-02-05 Thread Alin Serdean 
getrusage is implemented in lib/getrusage-windows.c.

This patch just adds its definition to include/windows/sys/resource.h,
which serves for files that include .

Another that we could also do is to move the implementation to
include/windows

Signed-off-by: Alin Gabriel Serdean 
---
 include/windows/sys/resource.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/windows/sys/resource.h b/include/windows/sys/resource.h
index d4628f2..d8f2607 100644
--- a/include/windows/sys/resource.h
+++ b/include/windows/sys/resource.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 Nicira, Inc.
+ * Copyright (c) 2014, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -48,4 +48,6 @@ struct rusage {
 #define RUSAGE_THREAD 3
 #endif
 
+int getrusage(int who, struct rusage *usage);
+
 #endif /* sys/resource.h */
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation

2017-02-05 Thread Shashank Ram 
Thanks Alin for clarifying. Like Nithin already mentioned in his response, I 
think we should keep it as is to be more explicit in the documentation. The 
documentation in the context of this patch is only providing an example, and if 
someone felt it were too long to type, they would just use copy-paste.


You could instead make the documentation clearer by mentioning that the name 
here is just an example, by saying something along the lines - To create a new 
Hyper-V switch with the name "OVS-Extended-Switch", 


Thanks,

Shashank


From: Alin Serdean 
Sent: Sunday, February 5, 2017 3:12:57 PM
To: Shashank Ram; d...@openvswitch.org
Subject: RE: [PATCH 4/4] doc-windows: Consolidate switch names in documentation

Hi Shashank,
Thanks for reviewing the patch!
The main problem is we have two switch names defined currently in the 
documentation. I wanted to change it to have only one.
Sorry I wasn’t clear in the commit message.
The idea is we instruct to create a switch named `OVS-Extended-Switch`. For a 
sysadmin typing that name later on would be annoying when they want to do 
operation on the switch. I.e.: if they want to check if the extension is 
enabled they would have to issue the following command:
Get-VMSwitchExtension -VMSwitchName "OVS-Extended-Switch"
I usually create a switch with the name = switch type so it is easy to 
distinguish which does what, but point taken, some can find that confusing.
„ovsext-switch” is still long IMO and „ovsext” is the name of the running 
driver.

What about „ovs_switch” ?

Response to the other comment inlined.

Thanks,
Alin.

From: Shashank Ram [mailto:r...@vmware.com]
Sent: Sunday, February 5, 2017 9:21 AM
To: Alin Serdean 
>; 
d...@openvswitch.org
Subject: Re: [PATCH 4/4] doc-windows: Consolidate switch names in documentation

Hi Alin, I don't see a big value from this patch if I understand it correctly. 
Firstly, your commit is not clear about what it means when it says "typing it 
later on". Are you referring to typing it later on in the documentation? 
Secondly, since Hyper-V has different switch types such as "internal", 
"external", "private", replacing the switch name in the documentation with 
"external" might confuse readers unnecessarily, since its also a type. If you 
want to rename it, you could just call it something like "ovsext-switch" or 
just "ovsext".

Please find the other comments inline.

Thanks,
Shashank

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" `
+   PS > New-VMSwitch external -NetAdapterName "Ethernet0" `
   -AllowManagementOS $false
[SR]: The commit msgh does not mention anything about the "AllowManagementOS" 
flag being added. What's the reason for this?
[Alin Serdean]: Sorry that was intended to be included in patch 1

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

[ovs-dev] [PATCH] windows: Remove dead code in daemon-windows

2017-02-05 Thread Alin Serdean 
Found by inspection.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/daemon-windows.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/daemon-windows.c b/lib/daemon-windows.c
index 7e2e9da..4fc97a8 100644
--- a/lib/daemon-windows.c
+++ b/lib/daemon-windows.c
@@ -77,8 +77,7 @@ daemon_usage(void)
 "\nService options:\n"
 "  --service   run in background as a service.\n"
 "  --service-monitor   restart the service in case of an "
-   "unexpected failure. \n",
-ovs_rundir(), program_name);
+   "unexpected failure. \n");
 }
 
 /* Registers the call-back and configures the actions in case of a failure
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/4] doc-windows: Update supported tunnel ports

2017-02-05 Thread Alin Serdean 
Thanks for the review!

This patch will be respined once current issue is closed.

Alin.

> -Original Message-
> From: Nithin Raju [mailto:nit...@vmware.com]
> Sent: Sunday, February 5, 2017 10:42 AM
> To: Alin Serdean 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 2/4] doc-windows: Update supported tunnel
> ports
> 
> > On Feb 4, 2017, at 12:21 AM, Alin Serdean
>  wrote:
> >
> > Update the tunnel documentation as per:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_openvs
> >
> witch_ovs_blob_master_Documentation_faq_releases.rst=DwICAg=uil
> aK9
> > 0D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-
> mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=t1iOY
> > kV0imzVkI0uhClS440n8AR_pMp0Jey6PU7zd5k=xE9n-Xe-
> nFrheQbxmxmgFCuCDKxja
> > G2s3Ce4Q_xw0wE=
> >
> > Using the following command:
> > ovs-vsctl add-port br-int tun-2
> > will trigger an error because the type is not defined.
> > Update the documentation to chain commands so the error will not scare
> > users.
> >
> > Signed-off-by: Alin Gabriel Serdean 
> 
> Thanks for doing this.
> 
> Acked-by: Nithin Raju 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/4] doc-windows: Remove obsolete documentation

2017-02-05 Thread Alin Serdean 


From: Nithin Raju [mailto:nit...@vmware.com]
Sent: Sunday, February 5, 2017 10:45 AM
To: Alin Serdean 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 1/4] doc-windows: Remove obsolete documentation

Alin,
My suggestion would be to hold off on finalizing the documentation until we 
squash all the pending bugs. Looks like we are getting there.

Thanks,
-- Nithin
[Alin Serdean] Sure. I will respin the patches after the current issue is 
closed.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation

2017-02-05 Thread Alin Serdean 
Hi Shashank,
Thanks for reviewing the patch!
The main problem is we have two switch names defined currently in the 
documentation. I wanted to change it to have only one.
Sorry I wasn't clear in the commit message.
The idea is we instruct to create a switch named `OVS-Extended-Switch`. For a 
sysadmin typing that name later on would be annoying when they want to do 
operation on the switch. I.e.: if they want to check if the extension is 
enabled they would have to issue the following command:
Get-VMSwitchExtension -VMSwitchName "OVS-Extended-Switch"
I usually create a switch with the name = switch type so it is easy to 
distinguish which does what, but point taken, some can find that confusing.
"ovsext-switch" is still long IMO and "ovsext" is the name of the running 
driver.

What about "ovs_switch" ?

Response to the other comment inlined.

Thanks,
Alin.

From: Shashank Ram [mailto:r...@vmware.com]
Sent: Sunday, February 5, 2017 9:21 AM
To: Alin Serdean 
>; 
d...@openvswitch.org
Subject: Re: [PATCH 4/4] doc-windows: Consolidate switch names in documentation

Hi Alin, I don't see a big value from this patch if I understand it correctly. 
Firstly, your commit is not clear about what it means when it says "typing it 
later on". Are you referring to typing it later on in the documentation? 
Secondly, since Hyper-V has different switch types such as "internal", 
"external", "private", replacing the switch name in the documentation with 
"external" might confuse readers unnecessarily, since its also a type. If you 
want to rename it, you could just call it something like "ovsext-switch" or 
just "ovsext".

Please find the other comments inline.

Thanks,
Shashank

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" `
+   PS > New-VMSwitch external -NetAdapterName "Ethernet0" `
   -AllowManagementOS $false
[SR]: The commit msgh does not mention anything about the "AllowManagementOS" 
flag being added. What's the reason for this?
[Alin Serdean]: Sorry that was intended to be included in patch 1

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

[ovs-dev] (no subject)

2017-02-05 Thread AIZDEVUMA PIEDĀVĀJUMS . 



Brauchen Sie ein Unternehmen / persönliche Darlehen? Wenn ja, wenden Sie sich 
an Justin Williams auf Ihr Darlehen, das Darlehen-Konto: E-Mail: 
sloanslimi...@gmail.com


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

Re: [ovs-dev] [PATCH 1/4] doc-windows: Remove obsolete documentation

2017-02-05 Thread Nithin Raju 
Alin,
My suggestion would be to hold off on finalizing the documentation until we 
squash all the pending bugs. Looks like we are getting there.

Thanks,
-- Nithin

On Feb 4, 2017, at 12:21 AM, Alin Serdean 
> wrote:

Hard dependancy on default internal port (AllowManagementOS) has been
removed.
Software checksums are part of the windows datapath.
Disconnecting/Connecting the VIF is no longer required.
Unit tests are enabled and passing for some time now...
The option to create a MSI has been added.

Signed-off-by: Alin Gabriel Serdean 
>
---
Documentation/intro/install/windows.rst | 50 +
1 file changed, 13 insertions(+), 37 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index caa9f40..1e7707f 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -117,21 +117,6 @@ The following explains the steps in some detail.
   under Bash. The remainder, prefixed by ``>``, are PowerShell commands and
   must be run in PowerShell.

-Install Requirements
-
-
-* Share network adaptors
-
-  We require that you don't disable the "Allow management operating system to
-  share this network adapter" under 'Virtual Switch Properties' > 'Connection
-  type: External network', in the HyperV virtual network switch configuration.
-
-* Checksum Offloads
-
-  While there is some support for checksum/segmentation offloads in software,
-  this is still a work in progress. Till the support is complete we recommend
-  disabling TX/RX offloads for both the VM's as well as the HyperV.
-
Bootstrapping
-

@@ -287,16 +272,15 @@ Enforcement' during boot.  The following commands can be 
used:
  You may have to restart the machine for the settings to take effect.

In the Virtual Switch Manager configuration you can enable the Open vSwitch
-Extension on an existing switch or create a new switch.  If you are using an
-existing switch, make sure to enable the "Allow Management OS" option for VXLAN
-to work (covered later).
+Extension on an existing switch or create a new switch.

The command to create a new switch named 'OVS-Extended-Switch' using a physical
NIC named 'Ethernet 1' is:

.. code-block:: ps1con

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1"
+   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" `
+  -AllowManagementOS $false

.. note::

@@ -517,22 +501,17 @@ assign a 'OVS port name' which is a unique name across 
all VIFs on this
Hyper-V.  The next step is to add the VIF to the ovsdb using its 'OVS port
name' as key.

-First, assign a unique 'OVS port name' to the VIF. The VIF needs to have been
-disconnected from the Hyper-V switch before assigning a 'OVS port name' to it.
-In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a
-VIF on a VM ``VM1``.  By using index 0 for ``$vnic``, the first VIF of the VM
-is being addressed.  After assigning the name ``ovs-port-a``, the VIF is
-connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is
-assumed to be the Hyper-V switch with OVS extension enabled.:
+First, assign a unique 'OVS port name' to the VIF.  In the example below, we
+assign a 'OVS port name' called ``ovs-port-a`` to a VIF on a VM ``VM1``.  By
+using index 0 for ``$vnic``, the first VIF of the VM is being addressed.  We
+assume that OVS extension is enabled on the Hyper-V vSwitch to which the VIF is
+connected:

.. code-block:: ps1con

   PS > import-module .\datapath-windows\misc\OVS.psm1
   PS > $vnic = Get-VMNetworkAdapter 
-   PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0]
   PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a
-   PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \
- -SwitchName OVS-Extended-Switch

Next, add the VIFs to ``br-int``:

@@ -556,8 +535,6 @@ Dumping the ports should show the additional ports that 
were just added:
ovs-vsctl show
   4cd86499-74df-48bd-a64d-8d115b12a9f2
   Bridge br-pif
-   Port "vEthernet (external)"
-   Interface "vEthernet (external)"
   Port "Ethernet0"
   Interface "Ethernet0"
   Port br-pif
@@ -677,9 +654,9 @@ Re-Add the VIF ports with the VLAN tag:
Add tunnels
~~~

-The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add
-tunnels. For example, first add the tunnel port between 172.168.201.101 <->
-172.168.201.102:
+Let us add tunnels between two endpoints.
+For example, first add the tunnel port between
+172.168.201.101 <-> 172.168.201.102:

.. code-block:: doscon

@@ -791,9 +768,8 @@ his development repository in github and triggering a new 
build.
TODO


-* Investigate the working of sFlow on Windows and re-enable the unit tests.
+*

Re: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation

2017-02-05 Thread Nithin Raju 
hi Alin,
I second Shashank’s thoughts. I prefer the name “OVS-Extended-Switch”, it makes 
documentation explicit. I’d prefer to keep it that way.

I’m sure that once users are familiar with the documentation, they can pretty 
much pick whatever name they want.

Thanks,
-- Nithin

On Feb 4, 2017, at 11:20 PM, Shashank Ram 
> wrote:

Hi Alin, I don't see a big value from this patch if I understand it correctly. 
Firstly, your commit is not clear about what it means when it says "typing it 
later on". Are you referring to typing it later on in the documentation? 
Secondly, since Hyper-V has different switch types such as "internal", 
"external", "private", replacing the switch name in the documentation with 
"external" might confuse readers unnecessarily, since its also a type. If you 
want to rename it, you could just call it something like "ovsext-switch" or 
just "ovsext".

Please find the other comments inline.

Thanks,
Shashank

From: ovs-dev-boun...@openvswitch.org 
> on 
behalf of Alin Serdean 
>
Sent: Saturday, February 4, 2017 12:21 AM
To: d...@openvswitch.org
Subject: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in 
documentation

Use shorter name for the Hyper-V vSwitch for simplicity of typing it
later on.

Signed-off-by: Alin Gabriel Serdean 
>
---
Documentation/intro/install/windows.rst | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index ece207d..2341b5c 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -274,12 +274,12 @@ Enforcement' during boot.  The following commands can be 
used:
In the Virtual Switch Manager configuration you can enable the Open vSwitch
Extension on an existing switch or create a new switch.

-The command to create a new switch named 'OVS-Extended-Switch' using a physical
-NIC named 'Ethernet0' is:
+The command to create a new switch named 'external' using a physical NIC named
+'Ethernet0' is:

.. code-block:: ps1con

-   PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" `
+   PS > New-VMSwitch external -NetAdapterName "Ethernet0" `
  -AllowManagementOS $false
[SR]: The commit msgh does not mention anything about the "AllowManagementOS" 
flag being added. What's the reason for this?

.. note::
@@ -293,7 +293,7 @@ An alternative way to do the same is to run the following 
command:

.. code-block:: ps1con

-   PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch
+   PS > Enable-VMSwitchExtension "Open vSwitch Extension" external

.. note::

--
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=6OuVHk-mnufSWzkKa74UkQ=ANt1MyWGWPCfbl8o7d8EK5wC138sS4Uuzm8XX4IsouA=WtqG4fs_RRxuNxJrrZZ7cK19KcdlqwhuzYpesaRapeE=
___
dev mailing list
d...@openvswitch.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=-xl6DPE_Y3uQD-mpZD7osBo2iL4s3jwdmSjTlGgjlsQ=ZJZdXeUyJK0yT5jDOnWAeAQaGx-FHZF4KNy12XRtQaM=3N8RJlWhGyZ1TYeGFMgqeb57WFfsO10eg2H7J2erhg0=

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