[ovs-dev] HOST to SWITCH packets
Hello I am working with the "void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb)" function in datapath.c If I am right this function deals with packets that is send from a switch to another switch, does it deal with packets that are passed from a host to a switch? My scenario is something like h1s1 does the packet send from h1 to s1 go to dis function? If not which function am I supposed to look into? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] RETURNED MAIL: DATA FORMAT ERROR
The original message was received at Fri, 23 Jan 2015 02:45:15 -0600 from [119.5.140.252] - The following addresses had permanent fatal errors - dev@openvswitch.org ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] DPDK Initialization in OVS: Modification done in DPDK initialization functions to reflect recent modifications to DPDK codebase
Hi Shankari, I can't see any attachment. Can you send the patch using git send-email ? Few questions - What version and recent changes in DPDK are you referring to? - What compiler/linker errors are you fixing? - Did you run make distcheck? FYI - There was a patch submitted for DPDK v1.8.0 support here, http://openvswitch.org/pipermail/dev/2014-December/049720.html The reason I ask about 'make distcheck' is in DPDK v1.8.0 there are mbuf changes where they use offsets to the data. Even with changing the underlying access methods to the buffers, there are some unit tests failing. In one case a change is needed to ofpbuf_resize__() to atomically move the buffer so that the base/offset combination is valid. There are some other failures that are being investigated. Thanks, Kevin. > -Original Message- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Shankari > Vaidyalingam > Sent: Friday, January 23, 2015 12:16 AM > To: Ben Pfaff > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH] DPDK Initialization in OVS: Modification done > in DPDK initialization > functions to reflect recent modifications to DPDK codebase > > Apologies. Forgot to to include the diffs in the attachment. > Please find enclosed the diffs along with the description of the changes. > > Regards > Shankari.V > > On Fri, Jan 23, 2015 at 4:37 AM, Ben Pfaff wrote: > > > On Fri, Jan 23, 2015 at 12:16:37AM +0530, Shankari Vaidyalingam wrote: > > > I have enclosed the changes made in OVS DPDK code. > > > I'm planning to submit these changes as a patch. > > > Without the changes mentioned in this patch, compiler and linker errors > > > (enclosed) are seen during the build. > > > Hence please review the changes (in the enclosed file) I have made in > > the > > > OVS code repository so that I can proceed further. > > > > Where is the file? > > > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/4] Apple Mac OSX Support for CTL commands
On 01/22/15 at 09:22pm, Ben Pfaff wrote: > On Fri, Jan 23, 2015 at 01:17:34AM +, Dave Tucker wrote: > > This patch sets adds Apple Mac OSX Support for the ovs-vsctl and > > ovs-ofctl. This is useful for administrators who are managing OVS > > instances and whose primary desktop environment is Apple OSX. > > > > So far only OSX 10.10 has been tested and the commands used are > > listed in INSTALL.OSX.md > > This sounds great (without looking at any patches yet). I love new > ports. +1 (Awesome Dave!) > I see that there's a free-for-open-source continuous integration service > for Mac OS X at https://hosted-ci.com/. It would be really nice to get > OVS set up there (or somewhere similar) once it builds on OS X. I haven't looked into hosted-ci but it sounds interesting a it's based on Jenkins. Travis recently added support for OS X builds so that might offer an easy first step but a full Jenkins environment would offer some additional value. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] test-sflow: Fix error message when a socket cannot be opened.
On 01/22/15 at 10:03pm, Ben Pfaff wrote: > The error message should name the socket, which is 'target', not argv[1], > which might be anything. > > Signed-off-by: Ben Pfaff Acked-by: Thomas Graf ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 1/4] autoconf: Add macros to detect Apple Mac OSX
On 01/23/15 at 01:17am, Dave Tucker wrote: > Signed-off-by: Dave Tucker Looks good. You might want to move the whitespace fixes into a separate commit. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] lib: Add Mac OSX compatability
On 01/23/15 at 01:17am, Dave Tucker wrote:
> diff --git a/lib/socket-util.c b/lib/socket-util.c
> index 8949da7..732fd89 100644
> --- a/lib/socket-util.c
> +++ b/lib/socket-util.c
> @@ -112,6 +112,11 @@ set_dscp(int fd, uint8_t dscp)
> return 0;
> #endif
>
> +#ifdef __APPLE__
> +/* ToDo: Look at OSX QoS API */
> +return 0;
> +#endif
I think IP_TOS should work fine on MacOSX [0]
[0]
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man4/ip.4.html
Maybe you can just #ifndef the TCLASS socket option call for OSX?
> diff --git a/lib/timeval.c b/lib/timeval.c
> index 6173aff..2c354de 100644
> --- a/lib/timeval.c
> +++ b/lib/timeval.c
> @@ -56,6 +56,19 @@ typedef unsigned int clockid_t;
> const static unsigned long long unix_epoch = 1164447360;
> #endif /* _WIN32 */
>
> +#ifdef __APPLE__
> +typedef unsigned int clockid_t;
> +
> +#ifndef CLOCK_MONOTONIC
> +#define CLOCK_MONOTONIC 0
> +#endif
> +
> +#ifndef CLOCK_REALTIME
> +#define CLOCK_REALTIME 0
> +#endif
An alternative would be to move the definitions for _WIN32 out of
the ifdef and use CLOCK_MONOTONIC=1 CLOCK_REALTIME=2 for both
WIN32 and OSX. I realize that it doesn't really mater for now as
both map to just a gettimeofday() call.
> +
> +#endif /* __APPLE__ */
> +
> /* Structure set by unixctl time/warp command. */
> struct large_warp {
> struct unixctl_conn *conn; /* Connection waiting for warp response. */
> @@ -417,6 +430,19 @@ clock_gettime(clock_t id, struct timespec *ts)
> }
> #endif /* _WIN32 */
>
> +#ifdef __APPLE__
> +//clock_gettime is not implemented on OSX
> +int
> +clock_gettime(clock_t id, struct timespec* ts) {
> +struct timeval now;
> +int rv = gettimeofday(&now, NULL);
> +if (rv) return rv;
> +ts->tv_sec = now.tv_sec;
> +ts->tv_nsec = now.tv_usec * 1000;
> +return 0;
> +}
This needs some style changes ;-)
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 3/4] ofproto: Fix duplicate wait function from OSX
On 01/23/15 at 01:17am, Dave Tucker wrote:
> Signed-off-by: Dave Tucker
> ---
> ofproto/ofproto-dpif.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index bf15d04..a922544 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -1591,6 +1591,8 @@ run(struct ofproto *ofproto_)
> return 0;
> }
>
> +// There is an issue with Darwin aliasing wait from sys/wait.h
> +#ifndef __APPLE__
> static void
> wait(struct ofproto *ofproto_)
> {
> @@ -1630,6 +1632,7 @@ wait(struct ofproto *ofproto_)
> seq_wait(udpif_dump_seq(ofproto->backer->udpif), ofproto->dump_seq);
> seq_wait(ofproto->pins_seq, ofproto->pins_seqno);
> }
> +#endif
I doubt that the Darwin implementation takes a struct ofproto ;-)
I think you have to rename the wait() function in ofproto-dpif.c to
something unique instead.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 4/4] docs: Add README.OSX.md
On 01/23/15 at 01:17am, Dave Tucker wrote: > Signed-off-by: Dave Tucker Acked-by: Thomas Graf ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] layer 3 ports and OVS_KEY_ATTR_PACKET_ETHERTYPE (was Re: [PATCH v8 5/5] datapath: add layer 3 support to ovs_packet_cmd_execute())
On 1/20/15 12:52 PM, Thomas Morin wrote: Hi Jarno, Lori, On 12/10/2014 02:45 AM, Jarno Rajahalme wrote: We should add a new metadata key field OVS_KEY_ATTR_PACKET_ETHERTYPE, that contains the ethertype of the associated packet attribute. While this would be strictly needed only for L3 packets, it would be cleaner to include it with all packets in packet misses. Then it could be used in flow setup and packet execution as well. Other packet type namespaces (like IP protocol) could be later supported defining new netlink attributes. A corresponding new field packet_ethertype needs to be added in struct pkt_metadata. This needs to be kept upto date in userspace code pushing and popping headers, so that the correct value gets passed to kernel execution. Having the tunneled payload type be passed between kernel and userspace via OVS_KEY_ATTR_PACKET_ETHERTYPE is something needed for MPLS/GRE too (see [1] below). With some hints from Jesse back in November, I've been working in the past weeks to see how much needed to be adapted based on your patch to add support for l3 GRE tunnel ports, and have this work for MPLS-over-GRE payloads. I've not everything covered yet, but I have the basic stuff working (with a kernel dataplane). Here is an outline of the things I did to support MPLS/GRE based on the current l3 port patch (l3_v9), and that I think that these are also relevant to simplify the code in the IP/non-MPLS case : - kernel: adapt ovs_nla_put_flow to include OVS_KEY_ATTR_PACKET_ETHERTYPE in the noethernet case (not done in the current l3_v9 patch, in which the kernel datapath consume a value given by userspace for a flow put or a command execute, but does not provides this info on a flow miss) - user: have odp_key_to_pkt_metadata determine md->packet_ethertype based on OVS_KEY_ATTR_PACKET_ETHERTYPE, rather than base on the presence of OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6) - user: similarly for parse_ethertype, to determine the ethertype (based on OVS_KEY_ATTR_PACKET_ETHERTYPE rather than base on the presence of OVS_KEY_ATTR_IPV4 or OVS_KEY_ATTR_IPV6) - user: have miniflow_extract rely on md->packet_ethertype for layer3 frames and do not use get_l3_eth_type anymore (which was guessing ethertype based on the version field of the IP header) - kernel: have ovs_key_from_nlattrs use OVS_KEY_ATTR_PACKET_ETHERTYPE, if present, to determine the ethertype Comments ? I will defer judgement to Jesse, Pravin, and Jarno. I don't mind changing the kernel/userspace API to this direction, it looks cleaner to me, although I don't know if it has significant performance or compatibility implications. Lori, I have the above working on my tree and will share code if we agree that this is the right direction. If there is consensus to use this approach I will pull your work into my tree and submit it along with my existing patches. Looking forward to feedback from the guys who reviewed my patches so far. -Lori Best, -Thomas [1] because MPLS can be used with two ethertypes (0x8847,0x8848) and a different semantic can be given to an MPLS label depending on the ethtype. This contrasts with IP, for which the ethertype can be guessed/derived from the presence of OVS_KEY_ATTR_IPV(4|6) or the version field of the IP header. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 11/11] ofproto: Add NXM_NX_TUN_GBP_ID and NXM_NX_TUN_GBP_FLAGS
On 01/22/15 at 03:07pm, Ben Pfaff wrote: > On Thu, Jan 22, 2015 at 10:44:33PM +0100, Thomas Graf wrote: > > From: Madhu Challa > > > > Introduces two new NXMs to represent VXLAN-GBP [0] fields. > > > > actions=load:0x10->NXM_NX_TUN_GBP_ID[],NORMAL > > tun_gbp_id=0x10,actions=drop > > > > This enables existing VXLAN tunnels to carry security label > > information such as a SELinux context to other network peers. > > > > The values are carried to/from the datapath using the attribute > > OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS. > > > > [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy-00 > > > > Signed-off-by: Madhu Challa > > Can you please update ovs-ofctl(8) to describe the new fields? Please > do cite the Internet-Draft somewhere. Thanks for the reviews! Addressed both of your comments and added a couple of additional tests cases. I'll wait for reviews for the datapath bits and send a v2 afterwards. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/4] Apple Mac OSX Support for CTL commands
On Fri, Jan 23, 2015 at 5:16 AM, Thomas Graf wrote: > On 01/22/15 at 09:22pm, Ben Pfaff wrote: > > On Fri, Jan 23, 2015 at 01:17:34AM +, Dave Tucker wrote: > > > This patch sets adds Apple Mac OSX Support for the ovs-vsctl and > > > ovs-ofctl. This is useful for administrators who are managing OVS > > > instances and whose primary desktop environment is Apple OSX. > > > > > > So far only OSX 10.10 has been tested and the commands used are > > > listed in INSTALL.OSX.md > > > > This sounds great (without looking at any patches yet). I love new > > ports. > > +1 (Awesome Dave!) > > (Feeling the need to pile onto the "Dave is awesome" portion of this thread.) Awesome work Dave! > > I see that there's a free-for-open-source continuous integration service > > for Mac OS X at https://hosted-ci.com/. It would be really nice to get > > OVS set up there (or somewhere similar) once it builds on OS X. > > I haven't looked into hosted-ci but it sounds interesting a it's based > on Jenkins. Travis recently added support for OS X builds so that > might offer an easy first step but a full Jenkins environment would > offer some additional value. > I love the fact there are now all of these CI systems available for Open Source projects. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] lib: Add Mac OSX compatability
On 23 Jan 2015, at 11:37, Thomas Graf wrote:
On 01/23/15 at 01:17am, Dave Tucker wrote:
diff --git a/lib/socket-util.c b/lib/socket-util.c
index 8949da7..732fd89 100644
--- a/lib/socket-util.c
+++ b/lib/socket-util.c
@@ -112,6 +112,11 @@ set_dscp(int fd, uint8_t dscp)
return 0;
#endif
+#ifdef __APPLE__
+/* ToDo: Look at OSX QoS API */
+return 0;
+#endif
I think IP_TOS should work fine on MacOSX [0]
[0]
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man4/ip.4.html
Maybe you can just #ifndef the TCLASS socket option call for OSX?
Thanks for the pointer. Will look in to it.
diff --git a/lib/timeval.c b/lib/timeval.c
index 6173aff..2c354de 100644
--- a/lib/timeval.c
+++ b/lib/timeval.c
@@ -56,6 +56,19 @@ typedef unsigned int clockid_t;
const static unsigned long long unix_epoch = 1164447360;
#endif /* _WIN32 */
+#ifdef __APPLE__
+typedef unsigned int clockid_t;
+
+#ifndef CLOCK_MONOTONIC
+#define CLOCK_MONOTONIC 0
+#endif
+
+#ifndef CLOCK_REALTIME
+#define CLOCK_REALTIME 0
+#endif
An alternative would be to move the definitions for _WIN32 out of
the ifdef and use CLOCK_MONOTONIC=1 CLOCK_REALTIME=2 for both
WIN32 and OSX. I realize that it doesn't really mater for now as
both map to just a gettimeofday() call.
Ack. I'd prefer to keep it as is for now as I believe there is a better
way to handle this in Yosemite.
Unfortunately that means reading through a load of API docs.
+
+#endif /* __APPLE__ */
+
/* Structure set by unixctl time/warp command. */
struct large_warp {
struct unixctl_conn *conn; /* Connection waiting for warp response.
*/
@@ -417,6 +430,19 @@ clock_gettime(clock_t id, struct timespec *ts)
}
#endif /* _WIN32 */
+#ifdef __APPLE__
+//clock_gettime is not implemented on OSX
+int
+clock_gettime(clock_t id, struct timespec* ts) {
+struct timeval now;
+int rv = gettimeofday(&now, NULL);
+if (rv) return rv;
+ts->tv_sec = now.tv_sec;
+ts->tv_nsec = now.tv_usec * 1000;
+return 0;
+}
This needs some style changes ;-)
Wait, you mean its obvious I'm not a C coder?
Will take a look and see what I can do...
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 3/4] ofproto: Fix duplicate wait function from OSX
On 23 Jan 2015, at 11:38, Thomas Graf wrote:
On 01/23/15 at 01:17am, Dave Tucker wrote:
Signed-off-by: Dave Tucker
---
ofproto/ofproto-dpif.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index bf15d04..a922544 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -1591,6 +1591,8 @@ run(struct ofproto *ofproto_)
return 0;
}
+// There is an issue with Darwin aliasing wait from sys/wait.h
+#ifndef __APPLE__
static void
wait(struct ofproto *ofproto_)
{
@@ -1630,6 +1632,7 @@ wait(struct ofproto *ofproto_)
seq_wait(udpif_dump_seq(ofproto->backer->udpif),
ofproto->dump_seq);
seq_wait(ofproto->pins_seq, ofproto->pins_seqno);
}
+#endif
I doubt that the Darwin implementation takes a struct ofproto ;-)
Yeah I brute-forced a way around it that only generates some compile
time warnings :)
I think you have to rename the wait() function in ofproto-dpif.c to
something unique instead.
Sure. How does `ovs-wait` sound?
I'm assuming this will need renaming in *every* source file though
unless we can do some ifdef magic.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/4] Apple Mac OSX Support for CTL commands
On 23 Jan 2015, at 11:16, Thomas Graf wrote: On 01/22/15 at 09:22pm, Ben Pfaff wrote: On Fri, Jan 23, 2015 at 01:17:34AM +, Dave Tucker wrote: This patch sets adds Apple Mac OSX Support for the ovs-vsctl and ovs-ofctl. This is useful for administrators who are managing OVS instances and whose primary desktop environment is Apple OSX. So far only OSX 10.10 has been tested and the commands used are listed in INSTALL.OSX.md This sounds great (without looking at any patches yet). I love new ports. +1 (Awesome Dave!) I see that there's a free-for-open-source continuous integration service for Mac OS X at https://hosted-ci.com/. It would be really nice to get OVS set up there (or somewhere similar) once it builds on OS X. I haven't looked into hosted-ci but it sounds interesting a it's based on Jenkins. Travis recently added support for OS X builds so that might offer an easy first step but a full Jenkins environment would offer some additional value. Yes I looked at Travis' OSX support... It seems sufficient for what we would need, but is a little tricky due to the way the matrices are set up. Let's have a call some time next week to see what we can do :) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 3/4] ofproto: Fix duplicate wait function from OSX
On 01/23/15 at 04:10pm, Dave Tucker wrote: > > > On 23 Jan 2015, at 11:38, Thomas Graf wrote: > >I doubt that the Darwin implementation takes a struct ofproto ;-) > > Yeah I brute-forced a way around it that only generates some compile time > warnings :) > > >I think you have to rename the wait() function in ofproto-dpif.c to > >something unique instead. > > Sure. How does `ovs-wait` sound? > I'm assuming this will need renaming in *every* source file though unless we > can do some ifdef magic. Since it's ofproto layer, maybe ofp_wait()? Lucky for you it's a static function in ofproto-dpif.c so all users must be in ofproto-dpif.c itself ;-) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] lib: Add Mac OSX compatability
On 01/23/15 at 04:07pm, Dave Tucker wrote: > >This needs some style changes ;-) > > Wait, you mean its obvious I'm not a C coder? > Will take a look and see what I can do... Have a look at CodingStyle.md ;-) ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] HOST to SWITCH packets
On Fri, Jan 23, 2015 at 12:17 AM, Sree Vidya S D wrote: > Hello > > I am working with the > > "void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb)" > > function in datapath.c > > If I am right this function deals with packets that is send from a switch > to another switch, does it deal with packets that are passed from a host to > a switch? > > My scenario is something like > > h1s1 > > does the packet send from h1 to s1 go to dis function? Yes. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] INSTALL.DPDK.md: Provide a little a more consistency to documentation.
A few users (based on the reports in disc...@openvswitch.org) have been literally following the instructions in INSTALL.DPDK.md and mixing up pre-installed utilities and daemons with freshly compiled utilities because the current documentation does not consistently call out using utilities from the compiled sources. This commit updates DPDK documentation to ask users to do a 'make install' and then use the utilities and daemons directly from Linux PATH. It also adds github markup where applicable. Reported-by: Arkajit Ghosh Signed-off-by: Gurucharan Shetty --- AUTHORS |1 + INSTALL.DPDK.md | 92 ++- 2 files changed, 51 insertions(+), 42 deletions(-) diff --git a/AUTHORS b/AUTHORS index e502865..763c96a 100644 --- a/AUTHORS +++ b/AUTHORS @@ -198,6 +198,7 @@ Anton Matsiuk anton.mats...@gmail.com Anup Khadka khadka...@gmail.com Anuprem Chalvadiachalv...@vmware.com Ariel Tubaltsev atubalt...@vmware.com +Arkajit Ghosh arkajit.gh...@tcs.com Atzm Watanabe a...@stratosphere.co.jp Bastian Blank wa...@debian.org Ben Basler bbas...@nicira.com diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md index 2cc7636..c105c4b 100644 --- a/INSTALL.DPDK.md +++ b/INSTALL.DPDK.md @@ -91,35 +91,33 @@ Using the DPDK with ovs-vswitchd: Ref to http://www.dpdk.org/doc/quick-start for verifying DPDK setup. -4. Start ovsdb-server as discussed in [INSTALL.md] doc: +4. Follow the instructions in [INSTALL.md] to install only the + userspace daemons and utilities (via 'make install'). 1. First time only db creation (or clearing): -``` -mkdir -p /usr/local/etc/openvswitch -mkdir -p /usr/local/var/run/openvswitch -rm /usr/local/etc/openvswitch/conf.db -cd $OVS_DIR -./ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db \ - ./vswitchd/vswitch.ovsschema -``` + ``` + mkdir -p /usr/local/etc/openvswitch + mkdir -p /usr/local/var/run/openvswitch + rm /usr/local/etc/openvswitch/conf.db + ovsdb-tool create /usr/local/etc/openvswitch/conf.db \ + /usr/local/share/openvswitch/vswitch.ovsschema + ``` -2. start ovsdb-server + 2. Start ovsdb-server -``` -cd $OVS_DIR -./ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \ + ``` + ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \ --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ --private-key=db:Open_vSwitch,SSL,private_key \ --certificate=Open_vSwitch,SSL,certificate \ --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --pidfile --detach -``` + ``` 3. First time after db creation, initialize: -``` -cd $OVS_DIR -./utilities/ovs-vsctl --no-wait init -``` + ``` + ovs-vsctl --no-wait init + ``` 5. Start vswitchd: @@ -128,32 +126,38 @@ Using the DPDK with ovs-vswitchd: dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter for dpdk initialization. -export DB_SOCK=/usr/local/var/run/openvswitch/db.sock -./vswitchd/ovs-vswitchd --dpdk -c 0x1 -n 4 -- unix:$DB_SOCK --pidfile --detach + ``` + export DB_SOCK=/usr/local/var/run/openvswitch/db.sock + ovs-vswitchd --dpdk -c 0x1 -n 4 -- unix:$DB_SOCK --pidfile --detach + ``` - If allocated more than one GB hugepage (as for IVSHMEM), set amount and use NUMA - node 0 memory: + If allocated more than one GB hugepage (as for IVSHMEM), set amount and + use NUMA node 0 memory: -./vswitchd/ovs-vswitchd --dpdk -c 0x1 -n 4 --socket-mem 1024,0 \ - -- unix:$DB_SOCK --pidfile --detach + ``` + ovs-vswitchd --dpdk -c 0x1 -n 4 --socket-mem 1024,0 \ + -- unix:$DB_SOCK --pidfile --detach + ``` 6. Add bridge & ports To use ovs-vswitchd with DPDK, create a bridge with datapath_type "netdev" in the configuration database. For example: -`ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev` + `ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev` Now you can add dpdk devices. OVS expect DPDK device name start with dpdk - and end with portid. vswitchd should print (in the log file) the number of dpdk - devices found. + and end with portid. vswitchd should print (in the log file) the number + of dpdk devices found. -ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk -ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk + ``` + ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk + ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk + ``` -Once first DPDK port is added to vswitchd, it creates a Polling thread and -polls dpdk device in continuous loop. Therefore CPU utilization -for t
Re: [ovs-dev] appveyor - windows autobuild service
On Thu, Jan 22, 2015 at 9:19 PM, Ben Pfaff wrote: > The travis autobuilder has been pretty awesome for GNU/Linux continuous > integration. I'd like to have autobuilders for other platforms too. > After a few minutes searching, I see that appveyor.com offers a similar > service, with similar Github integration, for Windows builds. If anyone > has time and inclination to integrate this with OVS, I'd appreciate it. I will spend some time. > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] RFC: Geneve OpenFlow support.
This commit adds support for Geneve flow mods via two nicira extensions.
NXM_NX_TUN_METADATA for being able to match on tun_metadata nxms and
NXAST_RAW_TUN_METADATA for tun_metadata actions.
Matching
On the match side multiple NXM_NX_TUN_METADATA nxms can appear in a flow
mod in any order. tun_metadata options are learned as flows get created.
The option space is shared between all the flows for both match and
actions. Since a flow can contain in the worst case all possible options
the max space reserved for the options is limited to 255 bytes.
tun_metadata options are hashed into two tables.
1. maps (class, type) -> (len, offset)
Duplicates are not allowed, this the len is unique to a particular (class,type)
2. maps (offset) -> (class,type,len)
The flow stores the oxm data as it appears (without the length). Given this
and the fact that the metadata in the flow can contain holes the second table
is used to figure out how much to skip to decode the next option.
One of the side effect of maintaining the tables is that commands like
ovs-dpctl that directly talke to datapath do not have access to the table
and cannot use it to dump. Since the dp flow was already created and the
netlink message contains the length of the option this issue can be handled
without needing to consult the table. I plan to implement this via a separate
commit.
Two new commands are added to ovs-appctl to be able to dump and flush the
table.
tnl/meta/flush
tnl/meta/show
The other side affect of keeping a table is that when flows are deleted
we cannot necesarily remove and resuse the holes in the option space without
additional complexity. I have not yet figured out how to maintain a reference
count of the flows that are using a particular entry.
ovs-ofctl is expanded to be able to pass multiple tun_metadata options.
example:
ovs-ofctl add-flow br0
"tun_id=0x32,tun_src=12.1.1.5,tun_metadata=1234561122334455667788,tun_metadata=123478aabbccdd,in_port=1
actions=output:2"
Actions
===
A new action tun_metadata is added. Multiple of these actions can appear in
a flowmod. The actions consult the same table to figure out mappings.
example:
ovs-ofctl add-flow br0 "in_port=2
actions=set_tunnel:0x32,load:0xc010105->NXM_NX_TUN_IPV4_DST[],tun_metadata=1234561122334455667788,tun_metadata=123478aabbccdd,output:1"
Usage
=
tun_metadata options are intended to be used for geneve and designed as such.
However they provide an alternate way to configure other types of tunnels.
Consumers of this api need to provide
1. datapath (like geneve kmod)
2. nlattr_to_tun_metadata: function to convert netlink attributes
provided by datapath into tun metadata used for matching.
3. tun_metadata_to_nlattr: function to convert tun metadata into netlink
attributes for the particular datapath.
todo list:
1. add a flag to flow to optimize check for is_all_zeros
2. handle dpctl dump-flows
3. remove the hardcoded if (nxm_class(header) == 1 && nxm_field(header) == 38) {
in nxm_field_by_header().
Signed-off-by: Madhu Challa
---
build-aux/extract-ofp-fields |6 +-
lib/automake.mk |2 +
lib/flow.c | 13 +-
lib/flow.h |4 +-
lib/match.c | 22 ++-
lib/meta-flow.c | 152 +++--
lib/meta-flow.h | 48 --
lib/nx-match.c | 64 ++-
lib/odp-util.c | 20 ++-
lib/odp-util.h |2 +-
lib/ofp-actions.c| 78 -
lib/ofp-actions.h| 10 ++
lib/ofp-parse.c |7 +-
lib/ofp-util.c |2 +-
lib/packets.h|3 +
lib/tun-metadata.c | 384 ++
lib/tun-metadata.h | 44 +
ofproto/ofproto-dpif-xlate.c | 15 +-
tests/ofproto.at |7 +-
19 files changed, 820 insertions(+), 63 deletions(-)
create mode 100644 lib/tun-metadata.c
create mode 100644 lib/tun-metadata.h
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index b15b01d..415b9e3 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -19,7 +19,8 @@ TYPES = {"u8": 1,
"be32": 4,
"MAC": 6,
"be64": 8,
- "IPv6": 16}
+ "IPv6": 16,
+ "bytestring": 255}
FORMATTING = {"decimal":("MFS_DECIMAL", 1, 8),
"hexadecimal":("MFS_HEXADECIMAL", 1, 8),
@@ -30,7 +31,8 @@ FORMATTING = {"decimal":("MFS_DECIMAL", 1,
8),
"OpenFlow 1.1+ port": ("MFS_OFP_PORT_OXM", 4, 4),
"frag": ("MFS_FRAG", 1, 1),
"tunnel flags": ("MFS_TNL_FLAGS",2, 2),
- "TCP flags": ("MFS_TCP_FLAGS",2, 2)}
+ "TCP flags": ("MFS_TCP_FLAGS",2, 2),
+ "tun_metadata": ("MFS_TUN_METADATA", 1, 255)}
PREREQS = {"none": "MF
Re: [ovs-dev] HOST to SWITCH packets
On Fri, Jan 23, 2015 at 01:47:40PM +0530, Sree Vidya S D wrote: > I am working with the > > "void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb)" > > function in datapath.c > > If I am right this function deals with packets that is send from a switch > to another switch, does it deal with packets that are passed from a host to > a switch? This function processes every packet that goes through the switch. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] test-sflow: Fix error message when a socket cannot be opened.
On Fri, Jan 23, 2015 at 12:17:04PM +0100, Thomas Graf wrote: > On 01/22/15 at 10:03pm, Ben Pfaff wrote: > > The error message should name the socket, which is 'target', not argv[1], > > which might be anything. > > > > Signed-off-by: Ben Pfaff > > Acked-by: Thomas Graf Thanks, applied to master. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/4] lib: Add Mac OSX compatability
On Fri, Jan 23, 2015 at 01:17:36AM +, Dave Tucker wrote: > Signed-off-by: Dave Tucker > -#ifndef _WIN32 > +#if !defined(__APPLE__) && !defined(_WIN32) > static inline ovs_be64 > htonll(uint64_t n) It's probably time to add an autoconf test for htonll() instead of using OS-specific tests. > diff --git a/lib/timeval.c b/lib/timeval.c > index 6173aff..2c354de 100644 > --- a/lib/timeval.c > +++ b/lib/timeval.c > @@ -56,6 +56,19 @@ typedef unsigned int clockid_t; > const static unsigned long long unix_epoch = 1164447360; > #endif /* _WIN32 */ > > +#ifdef __APPLE__ > +typedef unsigned int clockid_t; > + > +#ifndef CLOCK_MONOTONIC > +#define CLOCK_MONOTONIC 0 > +#endif > + > +#ifndef CLOCK_REALTIME > +#define CLOCK_REALTIME 0 > +#endif > + > +#endif /* __APPLE__ */ I guess that we could just move the existing checks for these constants outside the "#ifdef _WIN32", and that's probably a better solution. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 3/4] ofproto: Fix duplicate wait function from OSX
On Fri, Jan 23, 2015 at 05:31:06PM +0100, Thomas Graf wrote: > On 01/23/15 at 04:10pm, Dave Tucker wrote: > > > > > > On 23 Jan 2015, at 11:38, Thomas Graf wrote: > > >I doubt that the Darwin implementation takes a struct ofproto ;-) > > > > Yeah I brute-forced a way around it that only generates some compile time > > warnings :) > > > > >I think you have to rename the wait() function in ofproto-dpif.c to > > >something unique instead. > > > > Sure. How does `ovs-wait` sound? > > I'm assuming this will need renaming in *every* source file though unless we > > can do some ifdef magic. > > Since it's ofproto layer, maybe ofp_wait()? How about ofproto_dpif_wait()? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 4/4] docs: Add README.OSX.md
On Fri, Jan 23, 2015 at 01:17:38AM +, Dave Tucker wrote: > +Usage > +- > + > +> NOTE: Currently the userspace utilities will *only* work with the > equivalent OVS version Why? > +Assuming you have an Open vSwitch instance listening on `ptcp:6640`, you can > interact with it as follows: > + > +ovs-vsctl --db=tcp:192.168.59.103:6640 show > +ovs-vsctl --db=tcp:192.168.59.103:6640 add-br br0 > +ovs-vsctl --db=tcp:192.168.59.103:6640 set-manager br0 ptcp:6653 It's unusual to have to specify --db, can't the defaults be set up to work properly? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] format_uint32_masked call for printing reg value in match_format
Hi,
I see that in ovs-2.3 onwards, we use format_uint32_masked from
match_format for printing register values. While use of format_uint32_masked
for printing recirc_id, dp_hash and pkt_mark are fine, register values can
have a legit value of 0. As format_uint32_masked uses "%#x", we may end up
seeing register values as 0 instead of something more meaningful 0x0 (ex.
reg8=0). It may be bit confusing and cause existing parsing scripts to
break. Instead, why not use the earlier ovs printing method for registers?
Just wondering, if we can put back the following code in match_format?
Thanks,
Sabya
match_format()
{
[..]
for (i = 0; i < FLOW_N_REGS; i++) {
switch (wc->masks.regs[i]) {
case 0:
break;
case UINT32_MAX:
ds_put_format(s, "reg%d=0x%"PRIx32",", i, f->regs[i]);
break;
default:
ds_put_format(s, "reg%d=0x%"PRIx32"/0x%"PRIx32",",
i, f->regs[i], wc->masks.regs[i]);
break;
}
}
[..]
}
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] format_uint32_masked call for printing reg value in match_format
On Fri, Jan 23, 2015 at 02:52:46PM -0800, Sabyasachi Sengupta wrote: > I see that in ovs-2.3 onwards, we use format_uint32_masked from > match_format for printing register values. While use of > format_uint32_masked for printing recirc_id, dp_hash and pkt_mark > are fine, register values can have a legit value of 0. As > format_uint32_masked uses "%#x", we may end up seeing register > values as 0 instead of something more meaningful 0x0 (ex. reg8=0). 0 is just as meaningful as 0x0, and shorter. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] format_uint32_masked call for printing reg value in match_format
Yes, just wondering about the flow parsing scripts out there that may be break.. On Fri, 23 Jan 2015, Ben Pfaff wrote: On Fri, Jan 23, 2015 at 02:52:46PM -0800, Sabyasachi Sengupta wrote: I see that in ovs-2.3 onwards, we use format_uint32_masked from match_format for printing register values. While use of format_uint32_masked for printing recirc_id, dp_hash and pkt_mark are fine, register values can have a legit value of 0. As format_uint32_masked uses "%#x", we may end up seeing register values as 0 instead of something more meaningful 0x0 (ex. reg8=0). 0 is just as meaningful as 0x0, and shorter. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] ovs-bugtool: Add --help message.
Seemed a little embarrassing when I realized that ovs-bugtool has no usage
message on a customer call this morning.
Signed-off-by: Ben Pfaff
---
utilities/bugtool/ovs-bugtool.in | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/ovs-bugtool.in
index 75fcd0e..2ede359 100755
--- a/utilities/bugtool/ovs-bugtool.in
+++ b/utilities/bugtool/ovs-bugtool.in
@@ -14,7 +14,7 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
# Copyright (c) 2005, 2007 XenSource Ltd.
-# Copyright (c) 2010, 2011, 2012, 2013 Nicira, Inc.
+# Copyright (c) 2010, 2011, 2012, 2013, 2015 Nicira, Inc.
#
# To add new entries to the bugtool, you need to:
@@ -383,6 +383,34 @@ def main(argv=None):
only_ovs_info = False
collect_all_info = True
+if '--help' in sys.argv:
+print """\
+%(argv0)s: create status report bundles to assist in problem diagnosis
+usage: %(argv0)s OPTIONS
+
+By default, %(argv0)s prompts for permission to collect each form of status
+information and produces a .tar.gz file as output.
+
+The following options are available.
+ --help display this help message, then exit
+ -s, --silent suppress most output to stdout
+
+Options for categories of data to collect:
+ --entries=CAP_A,CAP_B,... set categories of data to collect
+ --all collect all categories
+ --ovs collect only directly OVS-related info
+ --log-days=DAYScollect DAYS worth of old logs
+ -y, --yestoall suppress prompts to confirm collection
+ --capabilities print categories as XML on stdout, then exit
+
+Output options:
+ --output=FORMATset output format to one of tar tar.bz2 tar.gz zip
+ --output-fd=FD send output to FD instead of to a file
+ --unlimitedignore default limits on sizes of data collected
+ --debugprint ovs-bugtool debug info on stdout\
+""" % {'argv0': sys.argv[0]}
+sys.exit(0)
+
# we need access to privileged files, exit if we are not running as root
if os.getuid() != 0:
print >>sys.stderr, "Error: ovs-bugtool must be run as root"
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-bugtool: Add --help message.
Thx for fixing this,
--output-fd=FD is not valid option, do you mean --outfile and --outfd ?
Otherwise, looks good~
Acked-by: Alex Wang
On Fri, Jan 23, 2015 at 3:19 PM, Ben Pfaff wrote:
> Seemed a little embarrassing when I realized that ovs-bugtool has no usage
> message on a customer call this morning.
>
> Signed-off-by: Ben Pfaff
> ---
> utilities/bugtool/ovs-bugtool.in | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/
> ovs-bugtool.in
> index 75fcd0e..2ede359 100755
> --- a/utilities/bugtool/ovs-bugtool.in
> +++ b/utilities/bugtool/ovs-bugtool.in
> @@ -14,7 +14,7 @@
> # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> USA
> #
> # Copyright (c) 2005, 2007 XenSource Ltd.
> -# Copyright (c) 2010, 2011, 2012, 2013 Nicira, Inc.
> +# Copyright (c) 2010, 2011, 2012, 2013, 2015 Nicira, Inc.
>
> #
> # To add new entries to the bugtool, you need to:
> @@ -383,6 +383,34 @@ def main(argv=None):
> only_ovs_info = False
> collect_all_info = True
>
> +if '--help' in sys.argv:
> +print """\
> +%(argv0)s: create status report bundles to assist in problem diagnosis
> +usage: %(argv0)s OPTIONS
> +
> +By default, %(argv0)s prompts for permission to collect each form of
> status
> +information and produces a .tar.gz file as output.
> +
> +The following options are available.
> + --help display this help message, then exit
> + -s, --silent suppress most output to stdout
> +
> +Options for categories of data to collect:
> + --entries=CAP_A,CAP_B,... set categories of data to collect
> + --all collect all categories
> + --ovs collect only directly OVS-related info
> + --log-days=DAYScollect DAYS worth of old logs
> + -y, --yestoall suppress prompts to confirm collection
> + --capabilities print categories as XML on stdout, then exit
> +
> +Output options:
> + --output=FORMATset output format to one of tar tar.bz2
> tar.gz zip
> + --output-fd=FD send output to FD instead of to a file
> + --unlimitedignore default limits on sizes of data
> collected
> + --debugprint ovs-bugtool debug info on stdout\
> +""" % {'argv0': sys.argv[0]}
> +sys.exit(0)
> +
> # we need access to privileged files, exit if we are not running as
> root
> if os.getuid() != 0:
> print >>sys.stderr, "Error: ovs-bugtool must be run as root"
> --
> 1.7.10.4
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
