Re: [ovs-dev] Pure power. Pure joy. Best price ever.
Do you think sex may be fun! Try it yourself! http://hop.kz/9bpR ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] vtep: Move vtep IDL files into new "libvtep.la".
There's no reason to build it in "lib" and include it in "libopenvswitch.la". This commit moves it to "vtep" and includes it in a new "libvtep.la". Signed-off-by: Justin Pettit --- lib/.gitignore|3 --- lib/automake.mk | 15 +-- lib/vtep-idl.ann |9 - vtep/.gitignore |3 +++ vtep/automake.mk | 26 +- vtep/vtep-ctl.c |2 +- vtep/vtep-idl.ann |9 + 7 files changed, 39 insertions(+), 28 deletions(-) delete mode 100644 lib/vtep-idl.ann create mode 100644 vtep/vtep-idl.ann diff --git a/lib/.gitignore b/lib/.gitignore index cdaee87..9f6e924 100644 --- a/lib/.gitignore +++ b/lib/.gitignore @@ -14,8 +14,5 @@ /vswitch-idl.c /vswitch-idl.h /vswitch-idl.ovsidl -/vtep-idl.c -/vtep-idl.h -/vtep-idl.ovsidl /libopenvswitch.pc /libsflow.pc diff --git a/lib/automake.mk b/lib/automake.mk index 2acfe18..3629079 100644 --- a/lib/automake.mk +++ b/lib/automake.mk @@ -268,8 +268,6 @@ lib_libopenvswitch_la_SOURCES = \ lib/vlog.c \ lib/vswitch-idl.c \ lib/vswitch-idl.h \ - lib/vtep-idl.c \ - lib/vtep-idl.h \ lib/lldp/aa-structs.h \ lib/lldp/lldp.c \ lib/lldp/lldp-const.h \ @@ -436,10 +434,7 @@ MAN_FRAGMENTS += \ OVSIDL_BUILT += \ $(srcdir)/lib/vswitch-idl.c \ $(srcdir)/lib/vswitch-idl.h \ - $(srcdir)/lib/vswitch-idl.ovsidl \ - $(srcdir)/lib/vtep-idl.c \ - $(srcdir)/lib/vtep-idl.h \ - $(srcdir)/lib/vtep-idl.ovsidl + $(srcdir)/lib/vswitch-idl.ovsidl EXTRA_DIST += $(srcdir)/lib/vswitch-idl.ann VSWITCH_IDL_FILES = \ @@ -449,14 +444,6 @@ $(srcdir)/lib/vswitch-idl.ovsidl: $(VSWITCH_IDL_FILES) $(AM_V_GEN)$(OVSDB_IDLC) annotate $(VSWITCH_IDL_FILES) > $@.tmp && \ mv $@.tmp $@ -EXTRA_DIST += $(srcdir)/lib/vtep-idl.ann -VTEP_IDL_FILES = \ - $(srcdir)/vtep/vtep.ovsschema \ - $(srcdir)/lib/vtep-idl.ann -$(srcdir)/lib/vtep-idl.ovsidl: $(VTEP_IDL_FILES) - $(AM_V_GEN)$(OVSDB_IDLC) annotate $(VTEP_IDL_FILES) > $@.tmp && \ - mv $@.tmp $@ - lib/dirs.c: lib/dirs.c.in Makefile $(AM_V_GEN)($(ro_c) && sed < $(srcdir)/lib/dirs.c.in \ -e 's,[@]srcdir[@],$(srcdir),g' \ diff --git a/lib/vtep-idl.ann b/lib/vtep-idl.ann deleted file mode 100644 index 5ffe585..000 --- a/lib/vtep-idl.ann +++ /dev/null @@ -1,9 +0,0 @@ -# -*- python -*- - -# This code, when invoked by "ovsdb-idlc annotate" (by the build -# process), annotates vswitch.ovsschema with additional data that give -# the ovsdb-idl engine information about the types involved, so that -# it can generate more programmer-friendly data structures. - -s["idlPrefix"] = "vteprec_" -s["idlHeader"] = "\"lib/vtep-idl.h\"" diff --git a/vtep/.gitignore b/vtep/.gitignore index c898bc4..2f13512 100644 --- a/vtep/.gitignore +++ b/vtep/.gitignore @@ -2,6 +2,9 @@ /Makefile.in /vtep-ctl /vtep-ctl.8 +/vtep-idl.c +/vtep-idl.h +/vtep-idl.ovsidl /vtep.5 /vtep.gv /vtep.ovsschema.stamp diff --git a/vtep/automake.mk b/vtep/automake.mk index a204d0a..494a225 100644 --- a/vtep/automake.mk +++ b/vtep/automake.mk @@ -1,3 +1,27 @@ +# vtep IDL +OVSIDL_BUILT += \ + vtep/vtep-idl.c \ + vtep/vtep-idl.h \ + vtep/vtep.ovsidl +EXTRA_DIST += vtep/vtep-idl.ann +VTEP_IDL_FILES = \ + vtep/vtep.ovsschema \ + vtep/vtep-idl.ann +vtep/vtep-idl.ovsidl: $(VTEP_IDL_FILES) + $(AM_V_GEN)$(OVSDB_IDLC) annotate $(VTEP_IDL_FILES) > $@.tmp && \ + mv $@.tmp $@ +CLEANFILES += vtep/vtep-idl.c vtep/vtep-idl.h + +# libvtep +lib_LTLIBRARIES += vtep/libvtep.la +vtep_libvtep_la_LDFLAGS = \ + -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ + -Wl,--version-script=$(top_builddir)/vtep/libvtep.sym \ + $(AM_LDFLAGS) +vtep_libvtep_la_SOURCES = \ + vtep/vtep-idl.c \ + vtep/vtep-idl.h + bin_PROGRAMS += \ vtep/vtep-ctl @@ -11,7 +35,7 @@ man_MANS += \ vtep/vtep-ctl.8 vtep_vtep_ctl_SOURCES = vtep/vtep-ctl.c -vtep_vtep_ctl_LDADD = lib/libopenvswitch.la +vtep_vtep_ctl_LDADD = vtep/libvtep.la lib/libopenvswitch.la # ovs-vtep scripts_SCRIPTS += \ diff --git a/vtep/vtep-ctl.c b/vtep/vtep-ctl.c index 7a7fd88..3e8066e 100644 --- a/vtep/vtep-ctl.c +++ b/vtep/vtep-ctl.c @@ -43,7 +43,7 @@ #include "smap.h" #include "sset.h" #include "svec.h" -#include "lib/vtep-idl.h" +#include "vtep/vtep-idl.h" #include "table.h" #include "timeval.h" #include "util.h" diff --git a/vtep/vtep-idl.ann b/vtep/vtep-idl.ann new file mode 100644 index 000..c53483f --- /dev/null +++ b/vtep/vtep-idl.ann @@ -0,0 +1,9 @@ +# -*- python -*- + +# This code, when invoked by "ovsdb-idlc annotate" (by the build +# process), annotates vswitch.ovsschema with additional data that give +# the ovsdb-idl engine information about the types involved, so that +# it can generate more programmer-friendly data structures. + +s["idlPrefix"] = "vteprec_" +s["idlHeader"] = "\"vtep/vtep-idl.h\"" -- 1.7.5.4 _
Re: [ovs-dev] These words make chicks horny?
Do you know how to make any girl horny for you? This Video Shows You How http://urla.ru/1HZw Just watch the video, use the tips, and start banging between 5 and 7 girls every week. If you want to use the tips to get a loyal dedicated girlfriend, you can use it for that too. And when you use this trick, there is no chance of rejection. So if you've ever been scared of "making your move" then this is for you. Watch The Video Now This video comes down tonight at midnight. So this is your only chance to watch. Go ahead and... Watch The Video Now http://urla.ru/1HZi And discover how to make any woman want to bang ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Fwd: Customized match options
Thank you very much Ben, your help is appreciated
2015-03-05 2:33 GMT+01:00 Ben Pfaff :
> On Wed, Mar 04, 2015 at 03:21:42PM -0800, Ben Pfaff wrote:
> > On Thu, Mar 05, 2015 at 12:06:14AM +0100, Raul Suarez Marin wrote:
> > > Thank you for your fast response. I configured my ovs with
> --enable-Werror
> > > and this allowed me to fix a couple warnings (unused variables). Sadly,
> > > looks like all changes that I should have done, are already done.
> > >
> > > The changes that the FAQ proposes are related to OF messages and flow
> entry
> > > installation. Now, I am missing the actual match, somewhere where I
> get the
> > > packet, and match some bytes.
> > >
> > > P.S.: I have created:
> > > --> the MFF_ variable in "enum OVS_PACKED_ENUM mf_field_id {"
> > > --> OFPXMT12_OFB_ "enum at enum oxm12_ofb_match_fields {"
> (openflow-1.2.h)
> > > --> OXM_OF_ (openflow-1.2.h)
> > > --> NXM_OF (nicita-ext.h)
> >
> > I guess you need to update miniflow_extract() in lib/flow.c then to
> > extract your new field. That's worth mentioning in the FAQ; I'll add
> > it. If you want kernel support then you have to add that to the
> > kernel module also.
>
> Done:
> http://openvswitch.org/pipermail/dev/2015-March/051997.html
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] netdev-dpdk: Fix build with unified RSS offload types in DPDK 2.0
RSS offload types were unified and simplified in DPDK 2.0, easily
handled with an ifdef though.
Signed-off-by: Panu Matilainen
---
lib/netdev-dpdk.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 1ba8310..b095826 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -97,8 +97,12 @@ static const struct rte_eth_conf port_conf = {
.rx_adv_conf = {
.rss_conf = {
.rss_key = NULL,
+#ifdef ETH_RSS_IPV4_TCP /* dpdk < 2.0 */
.rss_hf = ETH_RSS_IPV4_TCP | ETH_RSS_IPV4 | ETH_RSS_IPV6
| ETH_RSS_IPV4_UDP | ETH_RSS_IPV6_TCP | ETH_RSS_IPV6_UDP,
+#else
+.rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP,
+#endif
},
},
.txmode = {
--
2.1.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] this trick makes young women fuck you
A bold promise, I know... But i've recently discovered an absolutely GUARANTEED method for getting ANY woman into your bed. FAST And the best part is, you can use it TONIGHT to get laid. Click Here To Discover The Secret (Free Video) http://urla.ru/1HSj <- Videos comes down tonight - so watch it immediately. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] 1 trick for getting laid (video)
Seriously! Getting laid is simple All you have to do is read this email... And then watch this completely free video that shows you a scientifically-proven mind control trick that gets women turned on, attracted to you, and wanting to bang.within seconds. Click Here To Watch http://urla.ru/1HZT <- Best part? The trick is 100% rejection proof. And it's completely undetectable. Which means you'll never get "caught" using this... And you'll never get shot-down or embaressed. Simply use this trick And sit back as women do everything they can to get YOU into bed. Sound too good to be true? Well it's NOT And you can prove it to yourself just as soon as you watch this video and use it to get yourself some nice warm pussy Click Here To Watch Now http://urla.ru/1HZx <-- Enjoy! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] i guarantee you will get laid tonight (if you read this)
Can you get laid using the magic words in this video? Click Here To Find Out http://urla.ru/1HZ7 This shocking free video shows you how to make any girl want to fuck you in 60 seconds or less. Just say the magic words And any woman is yours. 100% of the time. Click Here To Watch The Video http://link.ac/4NeF80 You have to watch right now because the video is coming down at midnight. If you don't watch right now, then you will miss out forever. So go ahead and watch the video right now. Click Here To Watch The Video http://hop.kz/4Zhd ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
On 03/05/15 02:39, John Fastabend wrote: The intent was to reserve space in the tables for l2, l3, user space, and whatever else is needed. This reservation needs to come from the administrator because even the kernel doesn't know how much of my table space I want to reserve for l2 vs l3 vs tc vs ... The sizing of each of these tables will depend on the use case. If I'm provisioning L3 networks I may want to create a large l3 table and no 'tc' table. If I'm building a firewall box I might want a small l3 table and a large 'tc' table. Also depending on how wide I want my matches in the 'tc' case I may consume more or less resources in the hardware. Would kernel boot/module options passed to the driver not suffice? That implies a central authority that decides what these table size slicing looks like. Once the reservation of resources occurs we wouldn't let user space arbitrarily write to any table but only tables that have been explicitly reserved for user space to write to. How would one allow for a bypass to create tables (a write command) but not to write to said tables? likely i am missing something subtle. cheers, jamal ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
On 03/05/15 07:37, Jamal Hadi Salim wrote: On 03/05/15 02:39, John Fastabend wrote: Would kernel boot/module options passed to the driver not suffice? That implies a central authority that decides what these table size slicing looks like. Once the reservation of resources occurs we wouldn't let user space arbitrarily write to any table but only tables that have been explicitly reserved for user space to write to. Seems i misread what you are saying. I thought you wanted to just create the tables from user space directly; however, rereading the above: you are actually asking *to write* to these tables directly from user space ;-> cheers, jamal ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Xzu
The original message was received at Thu, 5 Mar 2015 20:33:47 +0700 from openvswitch.org [51.144.165.240] - The following addresses had permanent fatal errors - - Transcript of the session follows - ... while talking to server 16.83.4.127: 554 ... Mail quota exceeded 554 ... Service unavailable ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Strange trick makes girls fuck you?
Seriously! Getting laid is simple All you have to do is read this email... And then watch this completely free video that shows you a scientifically-proven mind control trick that gets women turned on, attracted to you, and wanting to bang.within seconds. Click Here To Watch http://hop.kz/4Zhg <- Best part? The trick is 100% rejection proof. And it's completely undetectable. Which means you'll never get "caught" using this... And you'll never get shot-down or embaressed. Simply use this trick And sit back as women do everything they can to get YOU into bed. Sound too good to be true? Well it's NOT And you can prove it to yourself just as soon as you watch this video and use it to get yourself some nice warm pussy Click Here To Watch Now http://link.ac/4NdZ8 <-- Enjoy! ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Returned mail: see transcript for details
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
On 03/05/2015 05:16 AM, Jamal Hadi Salim wrote: On 03/05/15 07:37, Jamal Hadi Salim wrote: On 03/05/15 02:39, John Fastabend wrote: Would kernel boot/module options passed to the driver not suffice? That implies a central authority that decides what these table size slicing looks like. The problem with boot/module options is they are really difficult to manage from a controller agent. And yes in most cases I am working on there is central authority that "knows" how to map the network policy onto a set of table size slices. At least in my space I don't believe people are logging into systems and using the CLI except for debugging and experimenting. Once the reservation of resources occurs we wouldn't let user space arbitrarily write to any table but only tables that have been explicitly reserved for user space to write to. Seems i misread what you are saying. I thought you wanted to just create the tables from user space directly; however, rereading the above: you are actually asking *to write* to these tables directly from user space ;-> Actually I was proposing both. But I can see a workaround for the set rule or *to write* by mapping a new xflow classifier onto my hardware. Not ideal for my work but I guess it might be possible. The 'create' table from user space though I don't see any good work around for. You need this in order to provide some guidance to the driver otherwise we have to try and "guess" what the table size slicing should look like and this can create rather large variations in how many rules fit in the table think 100 - 100k difference. Also at least on the hardware I have this is not dynamic I can't start adding rules to a table and then do a resizing later without disrupting the traffic. It would be interesting for folks working on other switch devices to chime in. Also just to the point out even in the 'set' case we wouldn't let arbitrary 'set rule' writes hit the hardware we would verify the rule set is for a table that is pre-defined for it and that the rule itself is well-formed. In that sense the xflow classifier path is not particularly different. cheers, jamal -- John Fastabend Intel Corporation ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] windows/syslog: Remove duplicate definition.
Signed-off-by: Gurucharan Shetty --- include/windows/syslog.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/windows/syslog.h b/include/windows/syslog.h index 3925ed6..242bfc4 100644 --- a/include/windows/syslog.h +++ b/include/windows/syslog.h @@ -26,7 +26,6 @@ #define LOG_INFO6 /* informational */ #define LOG_DEBUG 7 /* debug-level messages */ #define LOG_NDELAY 8 /* don't delay open */ -#define LOG_DAEMON 24 /* system daemons */ #define LOG_KERN (0<<3) /* kernel messages */ #define LOG_USER (1<<3) /* user-level messages */ -- 1.7.9.5 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] build mailing list down?
[moving to ovs-dev, hope that's OK] On Thu, Mar 05, 2015 at 03:52:42PM +, Gurucharan Shetty wrote: > It looks like there have been no emails for a while. > http://openvswitch.org/pipermail/build/ Hmm, looking at travis, there are definitely builds going, and some of them are failing, so it's either that travis isn't sending emails or that the list is not accepting them. Thomas, I seem to recall that you set up travis to send the emails; does anything need to change in that setup? Justin, is the list set up as one would expect? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
On 5 March 2015 at 20:22, John Fastabend wrote: > On 03/05/2015 05:16 AM, Jamal Hadi Salim wrote: >> Once the reservation of resources occurs we wouldn't let user space arbitrarily write to any table but only tables that have been explicitly reserved for user space to write to. >> >> >> Seems i misread what you are saying. >> I thought you wanted to just create the tables from user space >> directly; however, rereading the above: >> you are actually asking *to write* to these tables directly from user >> space ;-> >> >> > > Actually I was proposing both. But I can see a workaround for the set > rule or *to write* by mapping a new xflow classifier onto my hardware. > Not ideal for my work but I guess it might be possible. > > The 'create' table from user space though I don't see any good work > around for. You need this in order to provide some guidance to the > driver otherwise we have to try and "guess" what the table size slicing > should look like and this can create rather large variations in how > many rules fit in the table think 100 - 100k difference. Also at least > on the hardware I have this is not dynamic I can't start adding rules > to a table and then do a resizing later without disrupting the traffic. > It would be interesting for folks working on other switch devices to > chime in. Some of these abstractions are a little tough to map into for me. Probably I need more reading. But it is very interesting to follow the central resource manager notion. The question being asked is where this will be, user space or kernel space. The drivers (and the SDKs) I have worked upon provided a simple add rule , delete rule notion. They have hidden away the complexity of how it is managing stuff inside. They do tend to be complicated. For example, the simple question of how many rules can be supported inside a chip, doesn't have a single answer. It depends on how deep the packets need to be looked into, how many tags the packets are expected to be supported, ipv6, tunnels, tunnels inside tunnels and many other factors. Depending on the chip, some of the standard operations (such as vlans) are managed via rules, and some chips support them natively. This knowledge tends to be chip specific and very likely varies from chip to chip and manufacturer to manufacturer. Given this, the place the 'resources (rules)' need to be managed should be close to the chip, the driver. Kernel ? May be. It needs to define lot of 'generic' interfaces and manage in a single place. User space ? I don't think it can do it, not for the chips I am aware of. Note that by 'user space', I mean close to user and not an SDK running in user space. > > Also just to the point out even in the 'set' case we wouldn't let > arbitrary 'set rule' writes hit the hardware we would verify the rule > set is for a table that is pre-defined for it and that the rule itself > is well-formed. In that sense the xflow classifier path is not > particularly different. > > cheers, >> >> jamal > > > > -- > John Fastabend Intel Corporation > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] netdev-windows: Fix broken compilation.
Commit 6fd6ed71cb9f(ofpbuf: Simplify ofpbuf API.) removed ofpbuf_size and ofpbuf_data. They still had reference from netdev-windows. Fix them. Signed-off-by: Gurucharan Shetty --- lib/netdev-windows.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c index c67aaeb..1fc1da7 100644 --- a/lib/netdev-windows.c +++ b/lib/netdev-windows.c @@ -232,7 +232,7 @@ netdev_windows_netdev_from_ofpbuf(struct netdev_windows_netdev_info *info, netdev_windows_info_init(info); -ofpbuf_use_const(&b, ofpbuf_data(buf), ofpbuf_size(buf)); +ofpbuf_use_const(&b, buf->data, buf->size); nlmsg = ofpbuf_try_pull(&b, sizeof *nlmsg); genl = ofpbuf_try_pull(&b, sizeof *genl); ovs_header = ofpbuf_try_pull(&b, sizeof *ovs_header); -- 1.7.9.5 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it isn't there.
I've explained this a lot over the years.
Signed-off-by: Ben Pfaff
---
FAQ.md | 24
1 file changed, 24 insertions(+)
diff --git a/FAQ.md b/FAQ.md
index 5ee529c..fc4161c 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -772,6 +772,30 @@ A: If you add them one at a time with ovs-vsctl, it can
take a long
takes seconds, not minutes or hours, in the OVS sandbox environment.
+Q1: I created a bridge named br0. My bridge shows up in "ovs-vsctl
+show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
+or a socket".
+Q2: I have a bridge br0. I added a new port vif1.0, and it shows
+up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
+OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
+vif1.0 at all.
+
+A: Open vSwitch wasn't able to create the bridge or the port. Check
+ the ovs-vswitchd log for details (Debian and Red Hat packaging for
+ Open vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
+
+ In general, the Open vSwitch database reflects the desired
+ configuration state. ovs-vswitchd monitors the database and, when
+ it changes, reconfigures the system to reflect the new desired
+ state. This normally happens very quickly. Thus, a discrepancy
+ between the database and the actual state indicates that
+ ovs-vswitchd could not implement the configuration, and so one
+ should check the log to find out why. (Another possible cause is
+ that ovs-vswitchd is not running. This will make "ovs-vsctl"
+ commands hang, if they change the configuration, unless one
+ specifies "--no-wait".)
+
+
Quality of Service (QoS)
--
2.1.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] windows/syslog: Remove duplicate definition.
On Thu, Mar 05, 2015 at 06:58:52AM -0800, Gurucharan Shetty wrote: > Signed-off-by: Gurucharan Shetty Acked-by: Ben Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-windows: Fix broken compilation.
On Thu, Mar 05, 2015 at 07:30:12AM -0800, Gurucharan Shetty wrote: > Commit 6fd6ed71cb9f(ofpbuf: Simplify ofpbuf API.) removed ofpbuf_size > and ofpbuf_data. They still had reference from netdev-windows. Fix them. > > Signed-off-by: Gurucharan Shetty Acked-by: Ben Pfaff ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] vtep: Move vtep IDL files into new "libvtep.la".
On Thu, Mar 05, 2015 at 12:04:29AM -0800, Justin Pettit wrote: > There's no reason to build it in "lib" and include it in > "libopenvswitch.la". This commit moves it to "vtep" and includes it in > a new "libvtep.la". > > Signed-off-by: Justin Pettit I get a build failure when I apply this: make: Entering directory '/home/blp/nicira/ovs/_build' PYTHONPATH=../python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes /usr/bin/python ../ovsdb/ovsdb-idlc.in annotate vtep/vtep.ovsschema vtep/vtep-idl.ann > vtep/vtep-idl.ovsidl.tmp && \ mv vtep/vtep-idl.ovsidl.tmp vtep/vtep-idl.ovsidl Traceback (most recent call last): File "../ovsdb/ovsdb-idlc.in", line 866, in func(*args[1:]) File "../ovsdb/ovsdb-idlc.in", line 18, in annotateSchema schemaJson = ovs.json.from_file(schemaFile) File "/home/blp/nicira/ovs/python/ovs/json.py", line 136, in from_file stream = open(name, "r") IOError: [Errno 2] No such file or directory: 'vtep/vtep.ovsschema' Makefile:5307: recipe for target 'vtep/vtep-idl.ovsidl' failed make: *** [vtep/vtep-idl.ovsidl] Error 1 make: Target 'all' not remade because of errors. make: Leaving directory '/home/blp/nicira/ovs/_build' ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/8] vswitch: Document columns that had been previously overlooked.
On Wed, Feb 25, 2015 at 04:00:36PM +0100, Daniele Venturino wrote: > > +STP and RSTP are mutually exclusive. If both are enabled, RSTP > > +will be used. > > > I think this might not be true. > If it has not been changed, when STP or RSTP is enabled it should not be > possible to enable the other one on the same bridge. > This is done in bridge_configure_stp() and bridge_configure_rstp() in > vswitchd/bridge.c. Do you mean that, if the database enables both STP and RSTP, then which one becomes active depends on the order in which they are enabled? If so, then we should fix that: Open vSwitch configuration should be a function of the database's contents, not of the database's history. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-ofctl: batch together OFPC_ADD requests in add-flows command
On Wed, Mar 04, 2015 at 11:54:42AM -0800, Ansis Atteka wrote: > Until now "ovs-ofctl add-flows ..." command sent each OFPC_ADD > request one by one accompanied with a barrier request. This > meant that before ovs-ofctl could send next OFPC_ADD request > it had to wait for a barrier response that was sent together > with previous OFPC_ADD request. > > After this patch ovs-ofctl batches together all OFPC_ADD requests > and sends only a single barrier request for the last OFPC_ADD > request. As a result of this patch, ovs-ofctl was able to insert > 60K flows in 1 second instead of 7 seconds. This is especially > helpful when restarting ovs-vswitchd. > > One possible side effect of this patch is that ovs-ofctl > might ignore some error messages that resulted in failed > OFPC_ADD. That's a really nice speedup! However I'm worried about ignoring error messages. Why not report all of the errors, instead of ignoring them? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it isn't there.
On Thu, Mar 5, 2015 at 8:50 AM, Ben Pfaff wrote:
> I've explained this a lot over the years.
>
> Signed-off-by: Ben Pfaff
> ---
> FAQ.md | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/FAQ.md b/FAQ.md
> index 5ee529c..fc4161c 100644
> --- a/FAQ.md
> +++ b/FAQ.md
> @@ -772,6 +772,30 @@ A: If you add them one at a time with ovs-vsctl, it can
> take a long
>
> takes seconds, not minutes or hours, in the OVS sandbox environment.
>
> +Q1: I created a bridge named br0. My bridge shows up in "ovs-vsctl
> +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
> +or a socket".
> +Q2: I have a bridge br0. I added a new port vif1.0, and it shows
> +up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
> +OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
> +vif1.0 at all.
I think the Q2 is no longer true.
root@ubuntu-test:~# ovs-vsctl add-port br0 p20
ovs-vsctl: Error detected while setting up 'p20'. See ovs-vswitchd
log for details.
root@ubuntu-test:~# ovs-vsctl show
b1d3db14-03d2-4f3d-9db8-95d16441589a
Bridge "br0"
Port "p0"
Interface "p0"
Port "p20"
Interface "p20"
error: "could not open network device p20 (No such device)"
Port "br0"
Interface "br0"
type: internal
ovs_version: "2.3.90"
root@ubuntu-test:~#
> +
> +A: Open vSwitch wasn't able to create the bridge or the port. Check
> + the ovs-vswitchd log for details (Debian and Red Hat packaging for
> + Open vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
> +
> + In general, the Open vSwitch database reflects the desired
> + configuration state. ovs-vswitchd monitors the database and, when
> + it changes, reconfigures the system to reflect the new desired
> + state. This normally happens very quickly. Thus, a discrepancy
> + between the database and the actual state indicates that
> + ovs-vswitchd could not implement the configuration, and so one
> + should check the log to find out why. (Another possible cause is
> + that ovs-vswitchd is not running. This will make "ovs-vsctl"
> + commands hang, if they change the configuration, unless one
> + specifies "--no-wait".)
> +
> +
> Quality of Service (QoS)
>
>
> --
> 2.1.3
>
> ___
> 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] OVS Offload Decision Proposal
On 5 March 2015 at 22:03, B Viswanath wrote: > On 5 March 2015 at 20:22, John Fastabend wrote: >> On 03/05/2015 05:16 AM, Jamal Hadi Salim wrote: >>> > > Once the reservation of resources occurs we wouldn't let user space > arbitrarily write to any table but only tables that have been > explicitly reserved for user space to write to. >>> >>> >>> Seems i misread what you are saying. >>> I thought you wanted to just create the tables from user space >>> directly; however, rereading the above: >>> you are actually asking *to write* to these tables directly from user >>> space ;-> >>> >>> >> >> Actually I was proposing both. But I can see a workaround for the set >> rule or *to write* by mapping a new xflow classifier onto my hardware. >> Not ideal for my work but I guess it might be possible. >> >> The 'create' table from user space though I don't see any good work >> around for. You need this in order to provide some guidance to the >> driver otherwise we have to try and "guess" what the table size slicing >> should look like and this can create rather large variations in how >> many rules fit in the table think 100 - 100k difference. Also at least >> on the hardware I have this is not dynamic I can't start adding rules >> to a table and then do a resizing later without disrupting the traffic. >> It would be interesting for folks working on other switch devices to >> chime in. > > Some of these abstractions are a little tough to map into for me. > Probably I need more reading. But it is very interesting to follow > the central resource manager notion. The question being asked is where > this will be, user space or kernel space. > > The drivers (and the SDKs) I have worked upon provided a simple add > rule , delete rule notion. They have hidden away the complexity of how > it is managing stuff inside. They do tend to be complicated. For > example, the simple question of how many rules can be supported inside > a chip, doesn't have a single answer. It depends on how deep the > packets need to be looked into, how many tags the packets are expected > to be supported, ipv6, tunnels, tunnels inside tunnels and many other > factors. Depending on the chip, some of the standard operations (such > as vlans) are managed via rules, and some chips support them natively. > This knowledge tends to be chip specific and very likely varies from > chip to chip and manufacturer to manufacturer. > > Given this, the place the 'resources (rules)' need to be managed > should be close to the chip, the driver. Kernel ? May be. It needs to > define lot of 'generic' interfaces and manage in a single place. User > space ? I don't think it can do it, not for the chips I am aware of. > Note that by 'user space', I mean close to user and not an SDK > running in user space. I would like to mention couple of real world issues I faced in a previous life, with some of the switch chips, to support my argument about where the rules must be managed. 1. One of the chips required that I install three rules to just have a simple packet classification into a vlan, based on Source MAC. Two rules out of these three are work-around rules to avoid a bug on the silicon. One of the work around rules is needed to be installed only for the first mac-to-vlan classification rule . In other words, if a mac-to-vlan classification rule is already installed, I need to install just two rules. 2. Some chips can detect voice traffic, and automatically classify such traffic into a vlan. So no rules are necessary for voice-vlans. For some chips, a list of the OUI of the VOIP phones to be supported is configured as a set of rules for matching incoming packets. So, for a seemingly simple operation, the number of rules that will be exhausted out of the available set will vary depending on the chip. It gets very difficult to manage this rule set as we move away from the driver. Only the driver knows all the needed work-arounds to make something happen. Vissu > > >> >> Also just to the point out even in the 'set' case we wouldn't let >> arbitrary 'set rule' writes hit the hardware we would verify the rule >> set is for a table that is pre-defined for it and that the rule itself >> is well-formed. In that sense the xflow classifier path is not >> particularly different. >> >> cheers, >>> >>> jamal >> >> >> >> -- >> John Fastabend Intel Corporation >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] windows/syslog: Remove duplicate definition.
> On Mar 5, 2015, at 6:58 AM, Gurucharan Shetty wrote: > > Signed-off-by: Gurucharan Shetty Acked-by: Nithin Raju ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-windows: Fix broken compilation.
> On Mar 5, 2015, at 7:30 AM, Gurucharan Shetty wrote: > > Commit 6fd6ed71cb9f(ofpbuf: Simplify ofpbuf API.) removed ofpbuf_size > and ofpbuf_data. They still had reference from netdev-windows. Fix them. > > Signed-off-by: Gurucharan Shetty Thanks for the fix. Acked-by: Nithin Raju ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 2/8] vswitch: Document columns that had been previously overlooked.
I'm not sure, but if a user enabled one of them with
*ovs-vsctl set Bridge br0 stp_enable/rstp_enable=true*
and then the other one with
*ovs-vsctl set Bridge br0 rstp_enable/stp_enable=true*
this last command has no effects. See:
static void
> bridge_configure_rstp(struct bridge *br)
> {
> struct ofproto_stp_status stp_status;
> ofproto_get_stp_status(br->ofproto, &stp_status);
> if (!br->cfg->rstp_enable) {
> ofproto_set_rstp(br->ofproto, NULL);
> } else if (stp_status.enabled) {
> /* Do not activate RSTP if STP is enabled. */
> VLOG_ERR("RSTP cannot be enabled if STP is running.");
> ofproto_set_rstp(br->ofproto, NULL);
> ovsrec_bridge_set_rstp_enable(br->cfg, false);
> } else {
If enabling both of them should result in activating RSTP, then some
modifications are needed I think.
Daniele
2015-03-05 18:02 GMT+01:00 Ben Pfaff :
> On Wed, Feb 25, 2015 at 04:00:36PM +0100, Daniele Venturino wrote:
> > > +STP and RSTP are mutually exclusive. If both are
> enabled, RSTP
> > > +will be used.
> >
> >
> > I think this might not be true.
> > If it has not been changed, when STP or RSTP is enabled it should not be
> possible to enable the other one on the same bridge.
> > This is done in bridge_configure_stp() and bridge_configure_rstp() in
> vswitchd/bridge.c.
>
> Do you mean that, if the database enables both STP and RSTP, then which
> one becomes active depends on the order in which they are enabled? If
> so, then we should fix that: Open vSwitch configuration should be a
> function of the database's contents, not of the database's history.
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] rstp: add update_port_oper_point_to_point__().
Is this patch still pending? It doesn't change much, but it clarifies the correlation between admin_point_to_point_mac and oper_point_to_point_mac. Daniele 2014-12-11 20:59 GMT+01:00 Ben Pfaff : > On Mon, Nov 24, 2014 at 03:42:48PM +0100, Daniele Venturino wrote: > > With this patch, the effect of the admin_point_to_point_mac value on the > > oper_point_to_point_mac value is more clear. > > > > Signed-off-by: Daniele Venturino > > Jarno, it's been a while without a review. Are you planning to look at > this one? You're the team expert on RSTP, I think. > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] lib/rstp: Make rstp-disabled port forward stp bpdu packets.
I don't recall if we arrived at a decision about this.
Daniele
2014-11-24 15:02 GMT+01:00 Daniele Venturino :
>
> commit bacdb85ad82f981697245eefb40a3b360cfe379b
>> Author: Alex Wang
>> Date: Tue Jul 15 18:52:19 2014 -0700
>> stp: Make stp-disabled port forward stp bpdu packets.
>> Commit 0d1cee123a84 (stp: Fix bpdu tx problem in listening state)
>> makes ovs drop the stp bpdu packets if stp is not enabled on the
>> input port. However, when pif bridge is used and stp is enabled
>> on the integration bridge. The flow translation of stp bpdu
>> packets will go through a level of resubmission which changes
>> the input port to the corresponding peer port. Since, the
>> patch port on the pif bridge does not have stp enabled, the
>> flow translation will drop the bpdu packets.
>> This commit fixes the issue by making ovs forward stp bpdu packets
>> on stp-disabled port.
>> VMware-BZ: #1284695
>> Signed-off-by: Alex Wang
>> Acked-by: Ben Pfaff
>> Acked-by: Joe Stringer
>
>
>>
> Since the problem was that the bpdu packets were dropped if stp was not
> enabled on the input port, I think we can add the distinction between a
> port which has a disabled state with stp (or rstp) enabled and a port with
> stp (or rstp) not enabled in stp_should_forward_bpdu() and
> rstp_should_manage_bpdu() as well.
>
> If you think this is a good solution I’ve already prepared a patch.
>
> Regards,
> Daniele
>
> Il giorno 20/nov/2014, alle ore 23:39, Jarno Rajahalme <
> jrajaha...@nicira.com> ha scritto:
>
> Now that there is a difference between non-configured STP/RSTP and
> disabled STP/RSTP the situation may be different.
> If they still after this patch (considering the recent changes) will
> always return a fixed value, then yes.
>
> You should consider how the calling sites use these functions, as some of
> them changed in the last series that was merged recently.
>
> Jarno
>
> On Nov 20, 2014, at 11:35 AM, Daniele Venturino
> wrote:
>
> We didn’t merge this patch back in september.
> Were you suggesting to remove both stp_should_forward_bpdu() and
> rstp_should_manage_bpdu() ?
>
> Regards,
> Daniele
>
> Il giorno 11/set/2014, alle ore 16:11, Jarno Rajahalme <
> jrajaha...@nicira.com> ha scritto:
>
>
>
> Sent from my iPhone
>
> On Sep 11, 2014, at 2:08 AM, Daniele Venturino
> wrote:
>
>
> Il giorno 10/set/2014, alle ore 18:54, Jarno Rajahalme <
> jrajaha...@nicira.com> ha scritto:
>
> Daniele,
>
> See comments below.
>
> Also, it would be preferable to send related changes, or multiple
> unrelated changes to any given subsystem, as a series of patches instead of
> individual ones. “git format-patch” does that automatically.
>
> Jarno
>
>
> I’ll send the next group of patches as a series.
>
> On Sep 10, 2014, at 1:28 AM, Daniele Venturino
> wrote:
>
> See commit bacdb85ad82f981697245eefb40a3b360cfe379b.
>
> Signed-off by: Daniele Venturino
>
> ---
> lib/rstp.h | 42
> +++---
> ofproto/ofproto-dpif-xlate.c | 6 +++---
> 2 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/lib/rstp.h b/lib/rstp.h
> index 364a181..b15d22f 100644
> --- a/lib/rstp.h
> +++ b/lib/rstp.h
> @@ -99,6 +99,38 @@ typedef uint64_t rstp_identifier;
>
> #define RSTP_PORT_ID_FMT "%04"PRIx16
>
> +/* State of an RSTP port.
> + *
> + * The RSTP_DISABLED state means that the port is disabled by management.
> + * In our implementation, this state means that the port does not
> + * participate in the spanning tree, but it still forwards traffic as if
> + * it were in the RSTP_FORWARDING state. This may be different from
> + * other implementations.
> + *
> + * The following diagram describes the various states and what they are
> + * allowed to do in OVS:
> + *
> + * FWD LRN TX_BPDU RX_BPDU FWD_BPDU
> + * --- --- --- ---
> + *Disabled Y- - -Y
> + *Discarding-- Y YY
> + *Learning -Y Y YY
> + *ForwardingYY Y YY
> + *
> + *
> + * FWD: the port should forward any incoming non-rstp-BPDU
> + * packets.
> + *
> + * LRN: the port should conduct MAC learning on packets
> received.
> + *
> + * TX_BPDU/RX_BPDU: the port could generate/consume bpdus.
> + *
> + * FWD_BPDU: the port should should always forward the BPDUS,
> + * whether they are generated by the port or received
> + * as incoming packets.
> + *
> + */
> +
> enum rstp_state {
>RSTP_DISABLED,
>RSTP_LEARNING,
> @@ -128,7 +160,7 @@ const char *rstp_state_name(enum rstp_state);
> const char *rstp_port_role_name(enum rstp_port_role);
> static inline bool rstp_forward_in_state(enum rstp_state);
> static inline bool rstp_learn_in_state(enum rstp_state);
> -static inline bool rstp_shoul
Re: [ovs-dev] [PATCH 2/8] vswitch: Document columns that had been previously overlooked.
Thanks for confirming.
I sent out a patch to make behavior better resemble what ovs-vswitchd
does in other similar situations. Will you look at it? It is here:
http://openvswitch.org/pipermail/dev/2015-March/052049.html
On Thu, Mar 05, 2015 at 07:06:02PM +0100, Daniele Venturino wrote:
> I'm not sure, but if a user enabled one of them with
>
>
> *ovs-vsctl set Bridge br0 stp_enable/rstp_enable=true*
>
> and then the other one with
>
> *ovs-vsctl set Bridge br0 rstp_enable/stp_enable=true*
>
> this last command has no effects. See:
>
> static void
> > bridge_configure_rstp(struct bridge *br)
> > {
> > struct ofproto_stp_status stp_status;
> > ofproto_get_stp_status(br->ofproto, &stp_status);
> > if (!br->cfg->rstp_enable) {
> > ofproto_set_rstp(br->ofproto, NULL);
> > } else if (stp_status.enabled) {
> > /* Do not activate RSTP if STP is enabled. */
> > VLOG_ERR("RSTP cannot be enabled if STP is running.");
> > ofproto_set_rstp(br->ofproto, NULL);
> > ovsrec_bridge_set_rstp_enable(br->cfg, false);
> > } else {
>
>
>
> If enabling both of them should result in activating RSTP, then some
> modifications are needed I think.
>
> Daniele
>
> 2015-03-05 18:02 GMT+01:00 Ben Pfaff :
>
> > On Wed, Feb 25, 2015 at 04:00:36PM +0100, Daniele Venturino wrote:
> > > > +STP and RSTP are mutually exclusive. If both are
> > enabled, RSTP
> > > > +will be used.
> > >
> > >
> > > I think this might not be true.
> > > If it has not been changed, when STP or RSTP is enabled it should not be
> > possible to enable the other one on the same bridge.
> > > This is done in bridge_configure_stp() and bridge_configure_rstp() in
> > vswitchd/bridge.c.
> >
> > Do you mean that, if the database enables both STP and RSTP, then which
> > one becomes active depends on the order in which they are enabled? If
> > so, then we should fix that: Open vSwitch configuration should be a
> > function of the database's contents, not of the database's history.
> >
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] bridge: Enable RSTP if both STP and RSTP are enabled.
Until now, if both STP and RSTP were enabled, ovs-vswitchd would actually
enable only the one it first noticed to be enabled, and actually turn off
the setting for the other one in the database (!). This doesn't match
ovs-vswitchd behavior for other contradictory configurations, so this
commit changes its behavior so that, if both are enabled, RSTP takes
precedence.
Reported-by: Daniele Venturino
Signed-off-by: Ben Pfaff
---
vswitchd/bridge.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index f4ed174..dd622dc 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -248,8 +248,7 @@ static void bridge_configure_mac_table(struct bridge *);
static void bridge_configure_mcast_snooping(struct bridge *);
static void bridge_configure_sflow(struct bridge *, int *sflow_bridge_number);
static void bridge_configure_ipfix(struct bridge *);
-static void bridge_configure_stp(struct bridge *);
-static void bridge_configure_rstp(struct bridge *);
+static void bridge_configure_spanning_tree(struct bridge *);
static void bridge_configure_tables(struct bridge *);
static void bridge_configure_dp_desc(struct bridge *);
static void bridge_configure_aa(struct bridge *);
@@ -668,8 +667,7 @@ bridge_reconfigure(const struct ovsrec_open_vswitch
*ovs_cfg)
bridge_configure_netflow(br);
bridge_configure_sflow(br, &sflow_bridge_number);
bridge_configure_ipfix(br);
-bridge_configure_stp(br);
-bridge_configure_rstp(br);
+bridge_configure_spanning_tree(br);
bridge_configure_tables(br);
bridge_configure_dp_desc(br);
bridge_configure_aa(br);
@@ -1444,18 +1442,10 @@ port_configure_rstp(const struct ofproto *ofproto,
struct port *port,
/* Set spanning tree configuration on 'br'. */
static void
-bridge_configure_stp(struct bridge *br)
+bridge_configure_stp(struct bridge *br, bool enable_stp)
{
-struct ofproto_rstp_status rstp_status;
-
-ofproto_get_rstp_status(br->ofproto, &rstp_status);
-if (!br->cfg->stp_enable) {
-ofproto_set_stp(br->ofproto, NULL);
-} else if (rstp_status.enabled) {
-/* Do not activate STP if RSTP is enabled. */
-VLOG_ERR("STP cannot be enabled if RSTP is running.");
+if (!enable_stp) {
ofproto_set_stp(br->ofproto, NULL);
-ovsrec_bridge_set_stp_enable(br->cfg, false);
} else {
struct ofproto_stp_settings br_s;
const char *config_str;
@@ -1546,18 +1536,10 @@ bridge_configure_stp(struct bridge *br)
}
static void
-bridge_configure_rstp(struct bridge *br)
+bridge_configure_rstp(struct bridge *br, bool enable_rstp)
{
-struct ofproto_stp_status stp_status;
-
-ofproto_get_stp_status(br->ofproto, &stp_status);
-if (!br->cfg->rstp_enable) {
+if (!enable_rstp) {
ofproto_set_rstp(br->ofproto, NULL);
-} else if (stp_status.enabled) {
-/* Do not activate RSTP if STP is enabled. */
-VLOG_ERR("RSTP cannot be enabled if STP is running.");
-ofproto_set_rstp(br->ofproto, NULL);
-ovsrec_bridge_set_rstp_enable(br->cfg, false);
} else {
struct ofproto_rstp_settings br_s;
const char *config_str;
@@ -1652,6 +1634,22 @@ bridge_configure_rstp(struct bridge *br)
}
}
+static void
+bridge_configure_spanning_tree(struct bridge *br)
+{
+bool enable_rstp = br->cfg->rstp_enable;
+bool enable_stp = br->cfg->stp_enable;
+
+if (enable_rstp && enable_stp) {
+VLOG_WARN("%s: RSTP and STP are mutually exclusive but both are "
+ "configured; enabling RSTP", br->name);
+enable_stp = false;
+}
+
+bridge_configure_stp(br, enable_stp);
+bridge_configure_rstp(br, enable_rstp);
+}
+
static bool
bridge_has_bond_fake_iface(const struct bridge *br, const char *name)
{
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
I find it funny that we haven't even got a L3 forwarding implementation fleshed out enough to merge into the tree, and people are talking about VOIP to VLAN classification, hw bug workarounds, and shit like that. Everyone is really jumping the gun on all of this. Nobody knows what we will need, and I do mean nobody. Not me, not switch hardware guys, not people working on the code actively right now. Nobody. The only way to find out is to _do_, in small incremental steps, rather than big revolutionary changes. Simplify, consolidate, and optimize later. Let's get something that works for at least the simplest cases first. We don't even have that yet. So if people could drive their attention towards Scott's L3 forwarding work instead of this flow crap which is too far into the horizon to even be properly seen yet, I'd _really_ appreciate it. Thanks. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it isn't there.
On Thu, Mar 05, 2015 at 09:40:44AM -0800, Gurucharan Shetty wrote:
> On Thu, Mar 5, 2015 at 8:50 AM, Ben Pfaff wrote:
> > I've explained this a lot over the years.
> >
> > Signed-off-by: Ben Pfaff
> > ---
> > FAQ.md | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/FAQ.md b/FAQ.md
> > index 5ee529c..fc4161c 100644
> > --- a/FAQ.md
> > +++ b/FAQ.md
> > @@ -772,6 +772,30 @@ A: If you add them one at a time with ovs-vsctl, it
> > can take a long
> >
> > takes seconds, not minutes or hours, in the OVS sandbox environment.
> >
> > +Q1: I created a bridge named br0. My bridge shows up in "ovs-vsctl
> > +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
> > +or a socket".
> > +Q2: I have a bridge br0. I added a new port vif1.0, and it shows
> > +up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
> > +OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
> > +vif1.0 at all.
> I think the Q2 is no longer true.
>
> root@ubuntu-test:~# ovs-vsctl add-port br0 p20
> ovs-vsctl: Error detected while setting up 'p20'. See ovs-vswitchd
> log for details.
> root@ubuntu-test:~# ovs-vsctl show
> b1d3db14-03d2-4f3d-9db8-95d16441589a
> Bridge "br0"
> Port "p0"
> Interface "p0"
> Port "p20"
> Interface "p20"
> error: "could not open network device p20 (No such device)"
> Port "br0"
> Interface "br0"
> type: internal
> ovs_version: "2.3.90"
> root@ubuntu-test:~#
Yeah, it's true that newer versions are more helpful, but we still get
the question because not everyone is using the newest version.
How about this version?
--8<--cut here-->8--
From: Ben Pfaff
Date: Thu, 5 Mar 2015 11:20:56 -0800
Subject: [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it
isn't there.
I've explained this a lot over the years.
Signed-off-by: Ben Pfaff
---
FAQ.md | 34 ++
1 file changed, 34 insertions(+)
diff --git a/FAQ.md b/FAQ.md
index 5ee529c..0519721 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -772,6 +772,40 @@ A: If you add them one at a time with ovs-vsctl, it can
take a long
takes seconds, not minutes or hours, in the OVS sandbox environment.
+### Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl
+show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
+or a socket".
+
+A: Open vSwitch wasn't able to create the bridge. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
+
+ In general, the Open vSwitch database reflects the desired
+ configuration state. ovs-vswitchd monitors the database and, when
+ it changes, reconfigures the system to reflect the new desired
+ state. This normally happens very quickly. Thus, a discrepancy
+ between the database and the actual state indicates that
+ ovs-vswitchd could not implement the configuration, and so one
+ should check the log to find out why. (Another possible cause is
+ that ovs-vswitchd is not running. This will make "ovs-vsctl"
+ commands hang, if they change the configuration, unless one
+ specifies "--no-wait".)
+
+### I have a bridge br0. I added a new port vif1.0, and it shows
+up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
+OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
+vif1.0 at all.
+
+A: Open vSwitch wasn't able to create the port. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). Please
+ see the previous question for more information.
+
+ You may want to upgrade to Open vSwitch 2.3 (or later), in which
+ ovs-vsctl will immediately report when there is an issue creating a
+ port.
+
+
Quality of Service (QoS)
--
1.7.10.4
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it isn't there.
On Thu, Mar 5, 2015 at 11:21 AM, Ben Pfaff wrote:
> On Thu, Mar 05, 2015 at 09:40:44AM -0800, Gurucharan Shetty wrote:
>> On Thu, Mar 5, 2015 at 8:50 AM, Ben Pfaff wrote:
>> > I've explained this a lot over the years.
>> >
>> > Signed-off-by: Ben Pfaff
>> > ---
>> > FAQ.md | 24
>> > 1 file changed, 24 insertions(+)
>> >
>> > diff --git a/FAQ.md b/FAQ.md
>> > index 5ee529c..fc4161c 100644
>> > --- a/FAQ.md
>> > +++ b/FAQ.md
>> > @@ -772,6 +772,30 @@ A: If you add them one at a time with ovs-vsctl, it
>> > can take a long
>> >
>> > takes seconds, not minutes or hours, in the OVS sandbox environment.
>> >
>> > +Q1: I created a bridge named br0. My bridge shows up in "ovs-vsctl
>> > +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
>> > +or a socket".
>> > +Q2: I have a bridge br0. I added a new port vif1.0, and it shows
>> > +up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
>> > +OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
>> > +vif1.0 at all.
>> I think the Q2 is no longer true.
>>
>> root@ubuntu-test:~# ovs-vsctl add-port br0 p20
>> ovs-vsctl: Error detected while setting up 'p20'. See ovs-vswitchd
>> log for details.
>> root@ubuntu-test:~# ovs-vsctl show
>> b1d3db14-03d2-4f3d-9db8-95d16441589a
>> Bridge "br0"
>> Port "p0"
>> Interface "p0"
>> Port "p20"
>> Interface "p20"
>> error: "could not open network device p20 (No such device)"
>> Port "br0"
>> Interface "br0"
>> type: internal
>> ovs_version: "2.3.90"
>> root@ubuntu-test:~#
>
> Yeah, it's true that newer versions are more helpful, but we still get
> the question because not everyone is using the newest version.
>
> How about this version?
>
> --8<--cut here-->8--
>
> From: Ben Pfaff
> Date: Thu, 5 Mar 2015 11:20:56 -0800
> Subject: [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it
> isn't there.
>
> I've explained this a lot over the years.
>
> Signed-off-by: Ben Pfaff
> ---
> FAQ.md | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/FAQ.md b/FAQ.md
> index 5ee529c..0519721 100644
> --- a/FAQ.md
> +++ b/FAQ.md
> @@ -772,6 +772,40 @@ A: If you add them one at a time with ovs-vsctl, it can
> take a long
>
> takes seconds, not minutes or hours, in the OVS sandbox environment.
>
> +### Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl
> +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
> +or a socket".
> +
> +A: Open vSwitch wasn't able to create the bridge. Check the
> + ovs-vswitchd log for details (Debian and Red Hat packaging for Open
> + vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
> +
> + In general, the Open vSwitch database reflects the desired
> + configuration state. ovs-vswitchd monitors the database and, when
> + it changes, reconfigures the system to reflect the new desired
> + state. This normally happens very quickly. Thus, a discrepancy
> + between the database and the actual state indicates that
> + ovs-vswitchd could not implement the configuration, and so one
> + should check the log to find out why. (Another possible cause is
> + that ovs-vswitchd is not running. This will make "ovs-vsctl"
> + commands hang, if they change the configuration, unless one
> + specifies "--no-wait".)
> +
> +### I have a bridge br0. I added a new port vif1.0, and it shows
Missing 'Q'
Acked-by: Gurucharan Shetty
> +up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
> +OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
> +vif1.0 at all.
> +
> +A: Open vSwitch wasn't able to create the port. Check the
> + ovs-vswitchd log for details (Debian and Red Hat packaging for Open
> + vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). Please
> + see the previous question for more information.
> +
> + You may want to upgrade to Open vSwitch 2.3 (or later), in which
> + ovs-vsctl will immediately report when there is an issue creating a
> + port.
> +
> +
> Quality of Service (QoS)
>
>
> --
> 1.7.10.4
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Feel the love energy! Buy at our shop.
On the following pages you will gain a clear understanding of causes of ED and treatment methods. http://x.co/7q8rq & http://urla.ru/1HCC2 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] vtep: Move vtep IDL files into new "libvtep.la".
> On Mar 5, 2015, at 8:58 AM, Ben Pfaff wrote: > > On Thu, Mar 05, 2015 at 12:04:29AM -0800, Justin Pettit wrote: >> There's no reason to build it in "lib" and include it in >> "libopenvswitch.la". This commit moves it to "vtep" and includes it in >> a new "libvtep.la". >> >> Signed-off-by: Justin Pettit > > I get a build failure when I apply this: > >make: Entering directory '/home/blp/nicira/ovs/_build' >PYTHONPATH=../python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes > /usr/bin/python ../ovsdb/ovsdb-idlc.in annotate vtep/vtep.ovsschema > vtep/vtep-idl.ann > vtep/vtep-idl.ovsidl.tmp && \ >mv vtep/vtep-idl.ovsidl.tmp vtep/vtep-idl.ovsidl >Traceback (most recent call last): > File "../ovsdb/ovsdb-idlc.in", line 866, in >func(*args[1:]) > File "../ovsdb/ovsdb-idlc.in", line 18, in annotateSchema >schemaJson = ovs.json.from_file(schemaFile) > File "/home/blp/nicira/ovs/python/ovs/json.py", line 136, in from_file >stream = open(name, "r") >IOError: [Errno 2] No such file or directory: 'vtep/vtep.ovsschema' >Makefile:5307: recipe for target 'vtep/vtep-idl.ovsidl' failed >make: *** [vtep/vtep-idl.ovsidl] Error 1 >make: Target 'all' not remade because of errors. >make: Leaving directory '/home/blp/nicira/ovs/_build' I checked out a new tree and applied the patch, and it worked fine for me. I didn't move "vtep/vtep.ovsschema" from where it was before the patch, so I don't know why the file wouldn't exist. Can you take another look at your system just to make sure there's nothing off about your tree? Thanks, --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] vtep: Move vtep IDL files into new "libvtep.la".
On Thu, Mar 05, 2015 at 12:58:33PM -0800, Justin Pettit wrote: > > > On Mar 5, 2015, at 8:58 AM, Ben Pfaff wrote: > > > > On Thu, Mar 05, 2015 at 12:04:29AM -0800, Justin Pettit wrote: > >> There's no reason to build it in "lib" and include it in > >> "libopenvswitch.la". This commit moves it to "vtep" and includes it in > >> a new "libvtep.la". > >> > >> Signed-off-by: Justin Pettit > > > > I get a build failure when I apply this: > > > >make: Entering directory '/home/blp/nicira/ovs/_build' > >PYTHONPATH=../python":"$PYTHONPATH PYTHONDONTWRITEBYTECODE=yes > > /usr/bin/python ../ovsdb/ovsdb-idlc.in annotate vtep/vtep.ovsschema > > vtep/vtep-idl.ann > vtep/vtep-idl.ovsidl.tmp && \ > >mv vtep/vtep-idl.ovsidl.tmp vtep/vtep-idl.ovsidl > >Traceback (most recent call last): > > File "../ovsdb/ovsdb-idlc.in", line 866, in > >func(*args[1:]) > > File "../ovsdb/ovsdb-idlc.in", line 18, in annotateSchema > >schemaJson = ovs.json.from_file(schemaFile) > > File "/home/blp/nicira/ovs/python/ovs/json.py", line 136, in from_file > >stream = open(name, "r") > >IOError: [Errno 2] No such file or directory: 'vtep/vtep.ovsschema' > >Makefile:5307: recipe for target 'vtep/vtep-idl.ovsidl' failed > >make: *** [vtep/vtep-idl.ovsidl] Error 1 > >make: Target 'all' not remade because of errors. > >make: Leaving directory '/home/blp/nicira/ovs/_build' > > I checked out a new tree and applied the patch, and it worked fine for me. I > didn't move "vtep/vtep.ovsschema" from where it was before the patch, so I > don't know why the file wouldn't exist. Can you take another look at your > system just to make sure there's nothing off about your tree? I guess you build in your source directory. Fix: diff --git a/vtep/automake.mk b/vtep/automake.mk index 494a225..7892685 100644 --- a/vtep/automake.mk +++ b/vtep/automake.mk @@ -5,8 +5,8 @@ OVSIDL_BUILT += \ vtep/vtep.ovsidl EXTRA_DIST += vtep/vtep-idl.ann VTEP_IDL_FILES = \ - vtep/vtep.ovsschema \ - vtep/vtep-idl.ann + $(srcdir)/vtep/vtep.ovsschema \ + $(srcdir)/vtep/vtep-idl.ann vtep/vtep-idl.ovsidl: $(VTEP_IDL_FILES) $(AM_V_GEN)$(OVSDB_IDLC) annotate $(VTEP_IDL_FILES) > $@.tmp && \ mv $@.tmp $@ @@ -70,7 +70,7 @@ EXTRA_DIST += vtep/vtep.xml DISTCLEANFILES += vtep/vtep.5 man_MANS += vtep/vtep.5 vtep/vtep.5: \ - ovsdb/ovsdb-doc vtep/vtep.xml vtep/vtep.ovsschema $(VTEP_PIC) + ovsdb/ovsdb-doc vtep/vtep.xml $(srcdir)/vtep/vtep.ovsschema $(VTEP_PIC) $(AM_V_GEN)$(OVSDB_DOC) \ $(VTEP_DOT_DIAGRAM_ARG) \ --version=$(VERSION) \ ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] netdev-dpdk: Fix build with unified RSS offload types in DPDK 2.0
On Thu, Mar 5, 2015 at 1:29 AM, Panu Matilainen wrote:
> RSS offload types were unified and simplified in DPDK 2.0, easily
> handled with an ifdef though.
>
OVS does not support DPDK 2.0 yet. Is there any reason to introduce
the change at this point?
> Signed-off-by: Panu Matilainen
> ---
> lib/netdev-dpdk.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 1ba8310..b095826 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -97,8 +97,12 @@ static const struct rte_eth_conf port_conf = {
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> +#ifdef ETH_RSS_IPV4_TCP /* dpdk < 2.0 */
> .rss_hf = ETH_RSS_IPV4_TCP | ETH_RSS_IPV4 | ETH_RSS_IPV6
> | ETH_RSS_IPV4_UDP | ETH_RSS_IPV6_TCP | ETH_RSS_IPV6_UDP,
> +#else
> +.rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP,
> +#endif
> },
> },
> .txmode = {
> --
> 2.1.0
>
> ___
> 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] Be lovelier to love! Use or ED remedy.
Learn some useful lessons of being an awesome mistress from a wise woman! http://urla.ru/1HDY ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] this trick makes young women fuck you
A bold promise, I know... But i've recently discovered an absolutely GUARANTEED method for getting ANY woman into your bed. FAST And the best part is, you can use it TONIGHT to get laid. Click Here To Discover The Secret (Free Video) http://hop.kz/4Zh0 <- Videos comes down tonight - so watch it immediately. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [RFC ovn] ovn: Design and Schema changes for Container integration.
The design was come up after inputs and discussions with multiple people, including (in alphabetical order) Aaron Rosen, Ben Pfaff, Ganesan Chandrashekhar, Justin Pettit and Somik Behera. There are still some chinks around the OVN schema that needs to be sorted out. So this is a early version. Signed-off-by: Gurucharan Shetty --- ovn/CONTAINERS.md | 101 ovn/automake.mk|4 +- ovn/ovn-architecture.7.xml | 95 + ovn/ovn-nb.ovsschema |6 +++ ovn/ovn-nb.xml | 49 ++--- ovn/ovn.ovsschema |6 +++ ovn/ovn.xml| 45 +--- 7 files changed, 292 insertions(+), 14 deletions(-) create mode 100644 ovn/CONTAINERS.md diff --git a/ovn/CONTAINERS.md b/ovn/CONTAINERS.md new file mode 100644 index 000..0bc7eee --- /dev/null +++ b/ovn/CONTAINERS.md @@ -0,0 +1,101 @@ +Integration of Containers with OVN and Openstack + + +In a multi-tenant environment, creating containers directly on hypervisors +has many risks. A container application can break out and make changes to +the Open vSwitch flows and thus impact other tenants. This document +describes creation of containers inside VMs and how they can be made part +of the logical networks securely. The created logical network can include VMs, +containers and physical machines as endpoints. To better understand the +proposed integration of Containers with OVN and Openstack, this document +describes the end to end workflow with an example. + +* A OpenStack tenant creates a VM (say VM-A) with a single network interface +that belongs to a management logical network. The VM is meant to host +containers. OpenStack Nova chooses the hypervisor on which VM-A is created. + +* A logical port is created in Neutron with a port id that is same as the +vif-id associated with the virtual network interface (VIF) of VM-A. + +* When VM-A is created on a hypervisor, its VIF gets added to the +Open vSwitch integration bridge. This creates a row in the Interface table +of the Open_vSwitch database. As explained in the [IntegrationGuide.md], +the vif-id associated with the VM network interface gets added in the +external_ids:iface-id column of the newly created row in the Interface table. + +* Since VM-A belongs to a logical network, it gets an IP address. This IP +address is used to spawn containers (either manually or through container +orchestration systems) inside that VM and to monitor their health. + +* The vif-id associated with the VM's network interface can be obtained by +making a call to Neutron using tenant credentials. + +* All the calls to Neutron will need tenant credentials. These calls can +either be made from inside the tenant VM as part of a container network plugin +or from outside the tenant VM (if the tenant is not comfortable using temporary +Keystone tokens from inside the tenant VMs). For simplicity, this document +explains the work flow using the former method. + +* The container hosting VM will need Open vSwitch installed in it. The only +work for Open vSwitch inside the VM is to tag network traffic coming from +containers. + +* When a container needs to be created inside the VM with a container network +interface that is expected to be attached to a particular logical switch, the +network plugin in that VM chooses any unused VLAN (This VLAN tag only needs to +be unique inside that VM. This limits the number of Container interfaces to +4096 inside a single VM). This VLAN tag is stripped out in the hypervisor +by OVN and is only useful as a context (or metadata) for OVN. + +* The container network plugin then makes a call to Neutron to create a +logical port. In addition to all the inputs that a call to create a port in +Neutron is currently needed, it sends the vif-id and the VLAN tag as inputs. + +* Neutron in turn will verify that the vif-id belongs to the tenant in question +and then uses the OVN specific plugin to create a new row in the Logical_Port +table of the OVN Northbound Database. Neutron responds back with an +IP address and MAC address for that network interface. So Neutron becomes +the IPAM system and provides unique IP and MAC addresses across VMs and +Containers in the same logical network. + +* When a container is eventually deleted, the network plugin in that VM +will make a call to Neutron to delete that port. Neutron in turn will +delete the entry in the Logical_Port table of the OVN Northbound Database. + +As an example, consider Docker containers. Since Docker currently does not +have a network plugin feature, this example uses a hypothetical wrapper +around Docker to make calls to Neutron. + +* Create a Logical switch, e.g.: + +``` +% ovn-docker --cred=cca86bd13a564ac2a63ddf14bf45d37f create network LS1 +``` + +The above command will make a call to Neutron with the credentials to create
[ovs-dev] [PATCH v8] netdev-dpdk: add dpdk vhost-cuse ports
This patch adds support for a new port type to userspace datapath called dpdkvhost. This allows KVM (QEMU) to offload the servicing of virtio-net devices to its associated dpdkvhost port. Instructions for use are in INSTALL.DPDK. This has been tested on Intel multi-core platforms and with clients that have virtio-net interfaces. ver 8: - rebased with master ver 7: - rebased with master - reworked INSTALL.DPDK and performed extra testing based on review comments ver 6: - rebased with master - modified to use DPDK v1.8.0 vhost library - reworked for review comments ver 5: - rebased against latest master ver 4: - added eventfd_link.h and eventfd_link.c to EXTRA_DIST in utilities/automake.mk - rebased with master to work with DPDK 1.7 ver 3: - rebased with master ver 2: - rebased with master Signed-off-by: Ciara Loftus Signed-off-by: Kevin Traynor Signed-off-by: Maryam Tahhan --- INSTALL.DPDK.md | 260 +++ Makefile.am |4 + lib/automake.mk |1 + lib/netdev-dpdk.c | 649 +++ lib/netdev.c|3 +- utilities/automake.mk |3 +- utilities/qemu-wrap.py | 389 vswitchd/ovs-vswitchd.c |4 +- 8 files changed, 1201 insertions(+), 112 deletions(-) create mode 100755 utilities/qemu-wrap.py diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md index 276fe56..4deeb87 100644 --- a/INSTALL.DPDK.md +++ b/INSTALL.DPDK.md @@ -17,6 +17,7 @@ Building and Installing: Required DPDK 1.8.0 +Optional `fuse`, `fuse-devel` 1. Configure build & install DPDK: 1. Set `$DPDK_DIR` @@ -290,6 +291,264 @@ A general rule of thumb for better performance is that the client application should not be assigned the same dpdk core mask "-c" as the vswitchd. +DPDK vhost: +--- + +vhost-cuse is only supported at present i.e. not using the standard QEMU +vhost-user interface. It is intended that vhost-user support will be added +in future releases when supported in DPDK and that vhost-cuse will eventually +be deprecated. See [DPDK Docs] for more info on vhost. + +Prerequisites: +1. DPDK 1.8 with vhost support enabled and recompile OVS as above. + + Update `config/common_linuxapp` so that DPDK is built with vhost + libraries: + + `CONFIG_RTE_LIBRTE_VHOST=y` + +2. Insert the Cuse module: + + `modprobe cuse` + +3. Build and insert the `eventfd_link` module: + + `cd $DPDK_DIR/lib/librte_vhost/eventfd_link/` + `make` + `insmod $DPDK_DIR/lib/librte_vhost/eventfd_link.ko` + +Following the steps above to create a bridge, you can now add DPDK vhost +as a port to the vswitch. + +`ovs-vsctl add-port br0 dpdkvhost0 -- set Interface dpdkvhost0 type=dpdkvhost` + +Unlike DPDK ring ports, DPDK vhost ports can have arbitrary names: + +`ovs-vsctl add-port br0 port123ABC -- set Interface port123ABC type=dpdkvhost` + +However, please note that when attaching userspace devices to QEMU, the +name provided during the add-port operation must match the ifname parameter +on the QEMU command line. + + +DPDK vhost VM configuration: + + + vhost ports use a Linux* character device to communicate with QEMU. + By default it is set to `/dev/vhost-net`. It is possible to reuse this + standard device for DPDK vhost, which makes setup a little simpler but it + is better practice to specify an alternative character device in order to + avoid any conflicts if kernel vhost is to be used in parallel. + +1. This step is only needed if using an alternative character device. + + The new character device filename must be specified on the vswitchd + commandline: + +`./vswitchd/ovs-vswitchd --dpdk --basename my-vhost-net -c 0x1 ...` + + Note that the `--basename` argument and associated string must be the first + arguments after `--dpdk` and come before the EAL arguments. In the example + above, the character device to be used will be `/dev/my-vhost-net`. + +2. This step is only needed if reusing the standard character device. It will + conflict with the kernel vhost character device so the user must first + remove it. + + `rm -rf /dev/vhost-net` + +3a. Configure virtio-net adaptors: + The following parameters must be passed to the QEMU binary: + + ``` + -netdev tap,id=,script=no,downscript=no,ifname=,vhost=on + -device virtio-net-pci,netdev=net1,mac= + ``` + + Repeat the above parameters for multiple devices. + + The DPDK vhost library will negiotiate its own features, so they + need not be passed in as command line params. Note that as offloads are + disabled this is the equivalent of setting: + + `csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off` + +3b. If using an alternative character device. It must be also explicitly +passed to QEMU using the `vhostfd` argument: + + ``` + -netdev tap,id=,sc
Re: [ovs-dev] build mailing list down?
> Hmm, looking at travis, there are definitely builds going, and some of > them are failing, so it's either that travis isn't sending emails or > that the list is not accepting them. Thomas, I seem to recall that you > set up travis to send the emails; does anything need to change in that > setup? Justin, is the list set up as one would expect? If I am not wrong, you have added bu...@openvswitch.org to appveyor notifications. There have been a few build failures recently and I did not receive any mails. That was the reason of my question. > ___ > 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] vtep: Move vtep IDL files into new "libvtep.la".
> On Mar 5, 2015, at 1:12 PM, Ben Pfaff wrote: > > On Thu, Mar 05, 2015 at 12:58:33PM -0800, Justin Pettit wrote: >> >> I checked out a new tree and applied the patch, and it worked fine for me. >> I didn't move "vtep/vtep.ovsschema" from where it was before the patch, so I >> don't know why the file wouldn't exist. Can you take another look at your >> system just to make sure there's nothing off about your tree? > > I guess you build in your source directory. Fix: Yep, I do. Thanks for the fix. Since I got an off-line ACK, I went ahead and pushed it. --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] build mailing list down?
On Thu, Mar 05, 2015 at 01:59:51PM -0800, Gurucharan Shetty wrote: > > Hmm, looking at travis, there are definitely builds going, and some of > > them are failing, so it's either that travis isn't sending emails or > > that the list is not accepting them. Thomas, I seem to recall that you > > set up travis to send the emails; does anything need to change in that > > setup? Justin, is the list set up as one would expect? > If I am not wrong, you have added bu...@openvswitch.org to appveyor > notifications. There have been a few build failures recently and I did > not receive any mails. That was the reason of my question. I've been receiving appveyor emails directly to b...@nicira.com. Is it possible that I have something misconfigured so that I'm emailed instead of the list? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] build mailing list down?
> On Mar 5, 2015, at 8:11 AM, Ben Pfaff wrote: > > [moving to ovs-dev, hope that's OK] > > On Thu, Mar 05, 2015 at 03:52:42PM +, Gurucharan Shetty wrote: >> It looks like there have been no emails for a while. >> http://openvswitch.org/pipermail/build/ > > Hmm, looking at travis, there are definitely builds going, and some of > them are failing, so it's either that travis isn't sending emails or > that the list is not accepting them. Thomas, I seem to recall that you > set up travis to send the emails; does anything need to change in that > setup? Justin, is the list set up as one would expect? I just sent a test message to "bu...@openvswitch.org", and it worked as expected. --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Customized match options => miniflow_extract()
Hello,
I need new match options for my openvswitch. I have already sorted out the
flow_mod message handling and everything. Now, I need to find where the
match is performed, but I cannot find it. Through debugging, I found that
the matching is performed (or part of it) at miniflow_extract() at
lib\flow.c
However, as described in flow.h
/*
* The fields are organized in four segments to facilitate staged lookup,
where
* lower layer fields are first used to determine if the later fields need
to
* be looked at. This enables better wildcarding for datapath flows.
*
* NOTE: Order of the fields is significant, any change in the order must be
* reflected in miniflow_extract()!
*/
struct flow {
blablabla
}
What I did, is to take advantage of a padding field in flow structure, and
use it. This is now what miniflow_extract() assumes to be true (tcp_flags
and new field are 16-bit size).
BUILD_ASSERT_DECL(offsetof(struct flow, tcp_flags) + 2
== offsetof(struct flow, new_field) &&
offsetof(struct flow, tcp_flags) / 4
== offsetof(struct flow, new_field) / 4);
Then, in miniflow_extract(), I use the miniflow_push_be16(mf,
new_field, new_field); sentence (I do not know if this is correct).
Here is my question: where I have to take into account the order of the
fields, as stated in flow.h comment before definition of "struct flow"? Am
I missing/misunderstanding something?
I also do not understand how "miniflow structure" works, I know it is an
optimization of flow structure, but I do not know how it is formed or how
to read one.
ANY clue or documentation is useful.
Thank you for your support.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] BANNED Seduction Method?
Do you know how to make any girl horny for you? This Video Shows You How http://hop.kz/4Zhu Just watch the video, use the tips, and start banging between 5 and 7 girls every week. If you want to use the tips to get a loyal dedicated girlfriend, you can use it for that too. And when you use this trick, there is no chance of rejection. So if you've ever been scared of "making your move" then this is for you. Watch The Video Now This video comes down tonight at midnight. So this is your only chance to watch. Go ahead and... Watch The Video Now http://x.co/7sJwC And discover how to make any woman want to bang ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] OVS Offload Decision Proposal
On Wed, Mar 04, 2015 at 05:58:08PM -0800, John Fastabend wrote: > [...] > > >>>Doesn't this imply two entities to be independently managing the same > >>>physical resource? If so, this raises questions of how the resource > >>>would be partitioned between them? How are conflicting requests > >>>between the two rectified? > >> > >> > >>What two entities? The driver + flow API code I have in this case manage > >>the physical resource. > >> > >OVS and non-OVS kernel. Management in this context refers to policies > >for optimizing use of the HW resource (like which subset of flows to > >offload for best utilization). > > > >>I'm guessing the conflict you are thinking about is if we want to use > >>both L3 (or some other kernel subsystem) and OVS in the above case at > >>the same time? Not sure if people actually do this but what I expect is > >>the L3 sub-system should request a table from the hardware for L3 > >>routes. Then the driver/kernel can allocate a part of the hardware > >>resources for L3 and a set for OVS. > >> > >I'm thinking of this as a more general problem. We've established that > >the existing kernel mechanisms (routing, tc, qdiscs, etc) should and > >maybe are required to work with these HW offloads. I don't think that > >a model where we can't use offloads with OVS and kernel simultaneously > >would fly, nor are we going to want the kernel to be dependent on OVS > >for resource management. So at some point, these two are going to need > >to work together somehow to share common HW resources. By this > >reasoning, OVS offload can't be defined in a vacuum. Strict > >partitioning only goes so far an inevitably leads to poor resource > >utilization. For instance, if we gave OVS and kernel each 1000 flow > >states each to offload, but OVS has 2000 flows that are inundated and > >kernel ones are getting any traffic then we have achieved poor > >utilization. This problem becomes even more evident when someone adds > >rate limiting to flows. What would it mean if both OVS and kernel > >tried to instantiate a flow with guaranteed line rate bandwidth? It > >seems like we need either a centralized resource manager, or at least > >some sort of fairly dynamic delegation mechanism for managing the > >resource (presumably kernel is master of the resource). > > > >Maybe a solution to all of this has already been fleshed out, but I > >didn't readily see this in Simon's write-up. > In addition to Johns notes below, I think its important to keep in mind here that no one is explicitly setting out make OVS offload and kernel dataplane offload mutually exclusive, nor do I think that any of the available proposals are actually doing so. We just have two use cases that require different semantics to make efficient use of those offloads within their own environments. OVS, in Johns world requires fine grained control of the hardware dataplane, so that the OVS bridge can optimally pass off the most cycle constrained operations to the hardware, be that L2/L3, or some combination of both, in an effort to maximize whatever aggregate software/hardware datapath it wishes to construct based on user supplied rules. Alternatively, kernel functional offloads already have very well defined semantics, and more than anything else really just want to enforce those semantics in hardware to opportunistically accelerate data movement when possible, but not if it means sacrificing how the users interacts with those functions (routing should still act like routing, bridging like bridging, etc). That may require somewhat less efficient resource utilization than we could otherwise achieve in the hardware, but if the goal is semantic consistency, that may be a necessecary trade off. As to co-existence, theres no reason that both the models can't operate in parallel, as long as the API's for resource management collaborate under the covers. The only question is, does the hardware have enough resources to do both? I expect the answer is, not likely (though in some situations it may). But for that very reason we need to make that resource allocation an administrative decision. For kernel functionality, the only aspect of the offload that we should expose to the user is an on/off switch, and possibly some parameters with which to define offload resource sizing and policy. I.e. commands like: ip neigh offload enable dev sw0 cachesize 1000 policy lru to reserve 1000 entries to store l2 lookups with a least recently used replacement policy or ip route offload enable dev sw0 cachesize 1000 policy maxuse to reserve 1000 entries to store l3 lookups with a replacement policy that only replaces routes who's hit count is larger than the least used in the cache By enabling kernel functionality like that, remaining resources can be used by the lower level API for things like OVS to use. If there aren't enough left to enable OVS offload, so be it. the administrator has all the tools at their disposal with which to reduce resource usage
Re: [ovs-dev] [RFC ovn] ovn: Design and Schema changes for Container integration.
On 03/05/2015 03:28 PM, Gurucharan Shetty wrote: > The design was come up after inputs and discussions with multiple > people, including (in alphabetical order) Aaron Rosen, Ben Pfaff, > Ganesan Chandrashekhar, Justin Pettit and Somik Behera. There > are still some chinks around the OVN schema that needs to be > sorted out. So this is a early version. Cool stuff, thanks! > diff --git a/ovn/CONTAINERS.md b/ovn/CONTAINERS.md > new file mode 100644 > index 000..0bc7eee > --- /dev/null > +++ b/ovn/CONTAINERS.md > @@ -0,0 +1,101 @@ > +Integration of Containers with OVN and Openstack micro-nit: OpenStack (capitalization here and elsewhere) > + > + > +In a multi-tenant environment, creating containers directly on hypervisors > +has many risks. A container application can break out and make changes to > +the Open vSwitch flows and thus impact other tenants. This document > +describes creation of containers inside VMs and how they can be made part > +of the logical networks securely. The created logical network can include > VMs, > +containers and physical machines as endpoints. To better understand the > +proposed integration of Containers with OVN and Openstack, this document > +describes the end to end workflow with an example. > + > +* A OpenStack tenant creates a VM (say VM-A) with a single network interface > +that belongs to a management logical network. The VM is meant to host > +containers. OpenStack Nova chooses the hypervisor on which VM-A is created. > + > +* A logical port is created in Neutron with a port id that is same as the > +vif-id associated with the virtual network interface (VIF) of VM-A. I get what this is saying. It's not clear if the wording exactly matches what happens, though. Here's my attempt at expressing it: * A Neutron port may have been created in advance and passed in to Nova with the request to create a new VM. If not, Nova will issue a request to Neutron to create a new port. The ID of the logical port from Neutron will also be used as the vif-id for the virtual network interface (VIF) of VM-A. > +* When VM-A is created on a hypervisor, its VIF gets added to the > +Open vSwitch integration bridge. This creates a row in the Interface table > +of the Open_vSwitch database. As explained in the [IntegrationGuide.md], > +the vif-id associated with the VM network interface gets added in the > +external_ids:iface-id column of the newly created row in the Interface table. > + > +* Since VM-A belongs to a logical network, it gets an IP address. This IP > +address is used to spawn containers (either manually or through container > +orchestration systems) inside that VM and to monitor their health. This is a very minor clarification, but "their health" read as slightly confusing for me. It's not obvious if it means the health of the containers specifically or both the containers and the VM. I suppose either interpretation is fine, but rewording might help. > +* The vif-id associated with the VM's network interface can be obtained by > +making a call to Neutron using tenant credentials. > +* All the calls to Neutron will need tenant credentials. These calls can > +either be made from inside the tenant VM as part of a container network > plugin I figured out what this meant by "container network plugin" eventually, but it wasn't clear at first. It might be worth a bullet defining what "container network plugin" means. An attempt based on my understanding so far: * This flow assumes a logical component called a "container network plugin". Hypothetically, you could envision either a wrapper for docker or a feature of docker itself that understands how to perform part of this flow to get a container connected to a logical network managed by Neutron. The rest of the flow refers to this logical component that does not yet exist as the "container network plugin". > +or from outside the tenant VM (if the tenant is not comfortable using > temporary > +Keystone tokens from inside the tenant VMs). For simplicity, this document > +explains the work flow using the former method. > + > +* The container hosting VM will need Open vSwitch installed in it. The only > +work for Open vSwitch inside the VM is to tag network traffic coming from > +containers. > + > +* When a container needs to be created inside the VM with a container network > +interface that is expected to be attached to a particular logical switch, the > +network plugin in that VM chooses any unused VLAN (This VLAN tag only needs > to > +be unique inside that VM. This limits the number of Container interfaces to > +4096 inside a single VM). This VLAN tag is stripped out in the hypervisor > +by OVN and is only useful as a context (or metadata) for OVN. > + > +* The container network plugin then makes a call to Neutron to create a > +logical port. In addition to all the inputs that a call to create a port in > +Neutron is currently needed, it sends the
[ovs-dev] Strange trick makes girls fuck you?
Can you get laid using the magic words in this video? Click Here To Find Out http://urla.ru/1HYZ This shocking free video shows you how to make any girl want to fuck you in 60 seconds or less. Just say the magic words And any woman is yours. 100% of the time. Click Here To Watch The Video http://hop.kz/4Zh5 You have to watch right now because the video is coming down at midnight. If you don't watch right now, then you will miss out forever. So go ahead and watch the video right now. Click Here To Watch The Video http://x.co/7sJtS ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] bridge: Enable RSTP if both STP and RSTP are enabled.
On Thu, Mar 5, 2015 at 11:12 AM, Ben Pfaff wrote:
> Until now, if both STP and RSTP were enabled, ovs-vswitchd would actually
> enable only the one it first noticed to be enabled, and actually turn off
> the setting for the other one in the database (!). This doesn't match
> ovs-vswitchd behavior for other contradictory configurations, so this
> commit changes its behavior so that, if both are enabled, RSTP takes
> precedence.
>
> Reported-by: Daniele Venturino
> Signed-off-by: Ben Pfaff
Acked-by: Ansis Atteka
One small comment below.
> ---
> vswitchd/bridge.c | 46 ++
> 1 file changed, 22 insertions(+), 24 deletions(-)
>
> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
> index f4ed174..dd622dc 100644
> --- a/vswitchd/bridge.c
> +++ b/vswitchd/bridge.c
> @@ -248,8 +248,7 @@ static void bridge_configure_mac_table(struct bridge *);
> static void bridge_configure_mcast_snooping(struct bridge *);
> static void bridge_configure_sflow(struct bridge *, int
> *sflow_bridge_number);
> static void bridge_configure_ipfix(struct bridge *);
> -static void bridge_configure_stp(struct bridge *);
> -static void bridge_configure_rstp(struct bridge *);
> +static void bridge_configure_spanning_tree(struct bridge *);
> static void bridge_configure_tables(struct bridge *);
> static void bridge_configure_dp_desc(struct bridge *);
> static void bridge_configure_aa(struct bridge *);
> @@ -668,8 +667,7 @@ bridge_reconfigure(const struct ovsrec_open_vswitch
> *ovs_cfg)
> bridge_configure_netflow(br);
> bridge_configure_sflow(br, &sflow_bridge_number);
> bridge_configure_ipfix(br);
> -bridge_configure_stp(br);
> -bridge_configure_rstp(br);
> +bridge_configure_spanning_tree(br);
> bridge_configure_tables(br);
> bridge_configure_dp_desc(br);
> bridge_configure_aa(br);
> @@ -1444,18 +1442,10 @@ port_configure_rstp(const struct ofproto *ofproto,
> struct port *port,
>
> /* Set spanning tree configuration on 'br'. */
> static void
> -bridge_configure_stp(struct bridge *br)
> +bridge_configure_stp(struct bridge *br, bool enable_stp)
> {
> -struct ofproto_rstp_status rstp_status;
> -
> -ofproto_get_rstp_status(br->ofproto, &rstp_status);
> -if (!br->cfg->stp_enable) {
> -ofproto_set_stp(br->ofproto, NULL);
> -} else if (rstp_status.enabled) {
> -/* Do not activate STP if RSTP is enabled. */
> -VLOG_ERR("STP cannot be enabled if RSTP is running.");
> +if (!enable_stp) {
> ofproto_set_stp(br->ofproto, NULL);
> -ovsrec_bridge_set_stp_enable(br->cfg, false);
> } else {
> struct ofproto_stp_settings br_s;
> const char *config_str;
> @@ -1546,18 +1536,10 @@ bridge_configure_stp(struct bridge *br)
> }
>
> static void
> -bridge_configure_rstp(struct bridge *br)
> +bridge_configure_rstp(struct bridge *br, bool enable_rstp)
> {
> -struct ofproto_stp_status stp_status;
> -
> -ofproto_get_stp_status(br->ofproto, &stp_status);
> -if (!br->cfg->rstp_enable) {
> +if (!enable_rstp) {
> ofproto_set_rstp(br->ofproto, NULL);
> -} else if (stp_status.enabled) {
> -/* Do not activate RSTP if STP is enabled. */
> -VLOG_ERR("RSTP cannot be enabled if STP is running.");
> -ofproto_set_rstp(br->ofproto, NULL);
> -ovsrec_bridge_set_rstp_enable(br->cfg, false);
> } else {
> struct ofproto_rstp_settings br_s;
> const char *config_str;
> @@ -1652,6 +1634,22 @@ bridge_configure_rstp(struct bridge *br)
> }
> }
>
> +static void
> +bridge_configure_spanning_tree(struct bridge *br)
> +{
> +bool enable_rstp = br->cfg->rstp_enable;
> +bool enable_stp = br->cfg->stp_enable;
> +
> +if (enable_rstp && enable_stp) {
> +VLOG_WARN("%s: RSTP and STP are mutually exclusive but both are "
> + "configured; enabling RSTP", br->name);
Would you need to rate limit this VLOG_WARN() now?
> +enable_stp = false;
> +}
> +
> +bridge_configure_stp(br, enable_stp);
> +bridge_configure_rstp(br, enable_rstp);
> +}
> +
> static bool
> bridge_has_bond_fake_iface(const struct bridge *br, const char *name)
> {
> --
> 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
Re: [ovs-dev] [RFC 2/3] ovs-vsctl-bashcomp: Add bash command-line completion for ovs-vsctl.
Cool, I'll adopt the change and resend patches,
On Wed, Mar 4, 2015 at 6:33 PM, Peter Amidon wrote:
> These changes all look good to me, I really like the unit32_t-as-a-stack
> idea.
>
> ---Peter
>
> On Tue, 03 Mar 2015 21:41:11 -0800: Ben Pfaff wrote:
>
>
> On Mon, Feb 23, 2015 at 08:48:59AM -0800, Alex Wang wrote:
> >> From: Peter Amidon
> >>
> >> This patch adds bash command-line completion script for ovs-vsctl.
> >> Therein, codes are added to ovs-vsctl to allow it to print the
> >> options and command arguments. The ovs-vsctl-bashcomp.bash will
> >> parse the vsctl command and complete on the user input.
> >>
> >> The completion script can do the following::
> >>
> >> - display available completion and complete on user input for
> >> global/local options, command, and argument.
> >>
> >> - query database and expand keywords like 'table/record/column/key'
> >> to available completions.
> >>
> >> - deal with argument relations like 'one and more', 'zero or one'.
> >>
> >> - complete multiple ovs-vsctl commands cascaded via '--'.
> >>
> >> To use the script, either copy it inside /etc/bash_completion.d/
> >> or manually run it via . ovs-vsctl-bashcomp.bash.
> >>
> >> Signed-off-by: Alex Wang
>
> > Since I'm not a bash expert, I think I'll concentrate on the C code in
> > ovs-vsctl.c. Alex, have you reviewed the bash code? As long as you
> > have, I'm happy with it.
>
> > valgrind reports a buffer overrun when the length of command->argument
> > is 0.
>
> > It appears that print_command_arguments() uses a linked list to
> maintain
> > a stack of bools that will never get very deep. I think a single-word
> > bitmap would work just as well.
>
> > Here, you can omit the multiplication by sizeof(char), because the C
> > standard guarantees that sizeof(char) is 1:
> > char *simple_args = xzalloc(2 * length * sizeof(char));
>
> > 'in_repeated' should be declared bool and assigned true and false (not
> 0
> > and 1).
>
> > Please write a space around binary operators, e.g.
> arguments[length-i-1]
> > becomes arguments[length - i - 1].
>
> > It took me a minute to figure out what was going on with the output
> > buffer, that it's actually being written backward byte-by-byte. That's
> > brilliant, but I found the actual bookkeeping method difficult to
> > follow. This is a case where I find it a lot easier to understand when
> > there's a pointer to the current position that we decrement as we go.
>
> > Pretty much the same for the input buffer, although that's not quite as
> > hard to understand at first glance.
>
> > I think there's a missing "free" of the output buffer too.
>
> > There are double blank lines between functions. We don't generally do
> > that.
>
> > strlen(item) > 0 is more efficiently written item[0] != '\0'.
>
> > I usually try to write "break;" after every case in a switch statement,
> > even the last one, because it makes it harder to forget to add one if
> > you add another case later.
>
> > s/surronds/surrounds/ in the comment here:
> > * We use 'whole_word_is_optional' value to decide whether or not
> a ! or
> > * + should be added on encountering a space: if the optional
> surronds
> > * the whole word then it shouldn't be, but if it is only a part
> of the
>
> > I got interested in this so I actually implemented these changes.
> > Here's an incremental diff. I verified that it produces the same
> output
> > as the original version.
>
> > diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> > index 695ecd4..efd138c 100644
> > --- a/utilities/ovs-vsctl.c
> > +++ b/utilities/ovs-vsctl.c
> > @@ -768,94 +768,75 @@ static void
> > print_command_arguments(const struct vsctl_command_syntax *command)
> > {
> > /*
> > - * The argument string is parsed in reverse. We use a stack
> 'oew_stack'
> > - * to keep track of nested optionals. Whenever a ']' is
> encountered, we
> > - * push an element to 'oew_stack'. The 'optional_ends_word' is
> set if
> > - * the ']' is not nested. Subsequently, we pop an entry
> everytime '[' is
> > - * met.
> > + * The argument string is parsed in reverse. We use a stack
> 'oew_stack' to
> > + * keep track of nested optionals. Whenever a ']' is
> encountered, we push
> > + * a bit to 'oew_stack'. The bit is set to 1 if the ']' is not
> nested.
> > + * Subsequently, we pop an entry everytime '[' is met.
> > *
> > - * We use 'whole_word_is_optional' value to decide whether or not
> a ! or
> > - * + should be added on encountering a space: if the optional
> surronds
> > - * the whole word then it shouldn't be, but if it is only a part
> of the
> > - * word (i.e. [key=]value), it should be.
> > + * We use 'whole_word_is_optional' value to decide whether or not
> a ! or +
> > + * should be
Re: [ovs-dev] [PATCH] ovs-ofctl: batch together OFPC_ADD requests in add-flows command
On Thu, Mar 5, 2015 at 8:59 AM, Ben Pfaff wrote: > On Wed, Mar 04, 2015 at 11:54:42AM -0800, Ansis Atteka wrote: >> Until now "ovs-ofctl add-flows ..." command sent each OFPC_ADD >> request one by one accompanied with a barrier request. This >> meant that before ovs-ofctl could send next OFPC_ADD request >> it had to wait for a barrier response that was sent together >> with previous OFPC_ADD request. >> >> After this patch ovs-ofctl batches together all OFPC_ADD requests >> and sends only a single barrier request for the last OFPC_ADD >> request. As a result of this patch, ovs-ofctl was able to insert >> 60K flows in 1 second instead of 7 seconds. This is especially >> helpful when restarting ovs-vswitchd. >> >> One possible side effect of this patch is that ovs-ofctl >> might ignore some error messages that resulted in failed >> OFPC_ADD. > > That's a really nice speedup! > > However I'm worried about ignoring error messages. Why not report all > of the errors, instead of ignoring them? Reporting all errors (i.e. printing the actual OF message replies) might scare some users by flooding their consoles, if there would be a lot of flow-adds that failed. However, I think it might be good idea, as you suggested offline, to print amount of flow-adds that failed. Will think about this a little more. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [RFC 3/3] ovs-vsctl-bashcomp: Documentation and unit tests.
I found the issue but not the root cause, turns out, the autotest really does not like opening 'interactive shell' inside the AT_CHECK. The test hangs at (in function _ovs_vsctl_get_PS1): """ v="$(bash --norc --noprofile -i 2>&1 <<< $'PS1=\"'"$myPS1"$'\" \n# Begin prompt\n# End prompt')" """ Unfortunately, I could not find the root cause for this... In use the same way to get PS1 in my ovs-appctl-bashcomp.bash, however, I disable the function when running in test mode (that's why we did not see it in appctl completion tests). So, maybe we could do the same? What do you guys think?~ Thanks, Alex Wang, On Wed, Mar 4, 2015 at 9:33 AM, Alex Wang wrote: > > On Tue, Mar 3, 2015 at 9:51 PM, Ben Pfaff wrote: > >> On Mon, Feb 23, 2015 at 08:49:00AM -0800, Alex Wang wrote: >> > This commit includes the unit tests for ovs-vsctl-bashcomp >> > and refines the ovs-command-bashcomp.INSTALL.md to introduce >> > the bash completion for ovs-vsctl. >> > >> > Signed-off-by: Alex Wang >> >> It appears to me that there is something wrong with some of the tests or >> the code that it is testing. When I run "make check >> TESTSUITEFLAGS=-j10", tests 8 and 9 hang. When I then hit Control+C to >> kill the tests, I get a couple of "bash" processes that start using 100% >> CPU until I "kill -9" them. >> >> I don't get this behavior when I run plain "make check". Then the tests >> pass. >> >> > > Thx for the report, let me dig into it. > > > >> My bash version is: >> >> blp@sigabrt:~/nicira/ovs/_build(0)$ bash --version >> GNU bash, version 4.3.30(1)-release (i586-pc-linux-gnu) >> Copyright (C) 2013 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> >> This is free software; you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-ofctl: batch together OFPC_ADD requests in add-flows command
> Until now "ovs-ofctl add-flows ..." command sent each OFPC_ADD > request one by one accompanied with a barrier request. This > meant that before ovs-ofctl could send next OFPC_ADD request > it had to wait for a barrier response that was sent together > with previous OFPC_ADD request. > > After this patch ovs-ofctl batches together all OFPC_ADD requests > and sends only a single barrier request for the last OFPC_ADD > request. As a result of this patch, ovs-ofctl was able to insert > 60K flows in 1 second instead of 7 seconds. This is especially > helpful when restarting ovs-vswitchd. > > One possible side effect of this patch is that ovs-ofctl > might ignore some error messages that resulted in failed > OFPC_ADD. this seems like a semantic change in cases where the order of requests matter, right? have you considered to make it optional? YAMAMOTO Takashi ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] ovn: change type for router default_gw
The default_gw attribute of a logical router was defined as an IP
address in ovn-nb.xml, but as a boolean in ovn-nb.ovsschema. Fix the
schema to reflect that this is an IP address.
Signed-off-by: Russell Bryant
---
ovn/ovn-nb.ovsschema | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
index ad675ac..a02ad7e 100644
--- a/ovn/ovn-nb.ovsschema
+++ b/ovn/ovn-nb.ovsschema
@@ -45,7 +45,7 @@
"Logical_Router": {
"columns": {
"ip": {"type": "string"},
-"default_gw": {"type": {"key": "string", "min": 0, "max": 1}},
+"default_gw": {"type": "string"},
"external_ids": {
"type": {"key": "string", "value": "string",
"min": 0, "max": "unlimited",
--
2.1.0
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Bright life without ED. It's real! Order now.
According to the statistics, the problem of impotence concerns 21% of the stronger sex aged 20-30. http://x.co/7q9Kg ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Step into the future with new progressive medicine!
If you dont want to go under the knife for a chance of restored potency, try this drug! http://urla.ru/1HBy ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] kernel panic under heavy receive load
On Wed, Mar 04, 2015 at 03:56:41PM -0500, Xu (Simon) Chen wrote: > Now I think about it... Maybe I run into this problem because I turned on > Sflow collection on my OVS nodes... Yes, I was also running sflow collection. I think the bug will only bite when doing sflow collection because it's the sflow sampling that produces the "nla_type(a) == OVS_ACTION_ATTR_SAMPLE" in do_execute_actions() which then drops us into the problematical sample() function that shares the skb. So, for anyone coming across BUG() looking for answers... the quick solution is to turn off sflow collection, the permanent solution is to install v2.3.2 once it's out, and in the meantime you can cherry-pick commit d7ff93d75 on top of v2.3.1 to get your sflow collection working again. Cheers! Chris > On Wednesday, March 4, 2015, Chris Dunlop wrote: > > > On Sat, Feb 28, 2015 at 12:49:31PM +1100, Chris Dunlop wrote: > > > On Fri, Feb 27, 2015 at 08:30:42PM -0500, Xu (Simon) Chen wrote: > > > > On Fri, Feb 27, 2015 at 6:14 PM, Pravin Shelar > > wrote: > > > > > So it looks like vhost is generating shared skb. Can you try same > > test > > > > > on latest upstream kernel? > > > > > > > > I don't know whether it's vhost, as for me the VM receiving high volume > > > > consistently crashes. > > > > > > > > I previously had trouble building OVS datapath module on newer kernels. > > > > What is the latest kernel that I should try? > > > > > > According to: > > > > > > https://github.com/openvswitch/ovs/blob/master/FAQ.md > > > > > > ...v3.14 *is* the latest kernel supported by the out-of-tree OVS > > > kernel module, given that ovs 2.4.x isn't tagged yet and "git > > > log v2.3..master" doesn't reveal anything obviously aimed at > > > providing >v3.14 compatibility. > > > > > > Can you try with the in-tree OVS module? > > > > Simon, I think your crash will be fixed if you cherry-pick this > > openvswitch commit (from master) on top of v2.3.1: > > > > -- > > commit d7ff93d7532717ea9d610a7181f24c773170be80 > > Author: Andy Zhou > > > Date: Fri Aug 29 13:20:23 2014 -0700 > > > > datapath: simplify sample action implementation > > > > The current sample() function implementation is more complicated > > than necessary in handling single user space action optimization > > and skb reference counting. There is no functional changes. > > > > Signed-off-by: Andy Zhou > > > Acked-by: Pravin B Shelar > > > -- > > > > The commit isn't actually designed to address the problem directly, > > however in simplifying sample() it removes a call to skb_get(). The > > skb_get() makes the skb shared, which later causes us to hit the BUG(). > > E.g. your v2.3.1 stack trace shows this call path: > > > > netdev_frame_hook > > + netdev_port_receive > > | skb is guaranteed not-shared, via: > > | skb = skb_share_check(skb, GFP_ATOMIC); > > + ovs_vport_receive > > + ovs_dp_process_received_packet > > + ovs_dp_process_packet_with_key > > + ovs_execute_actions > > + do_execute_actions > > | nla_type(a) == OVS_ACTION_ATTR_SAMPLE > > + sample > > | skb is made shared here, via: > > | sample_skb = skb; > > | skb_get(skb); > > + do_execute_actions > > | nla_type(a) == OVS_ACTION_ATTR_USERSPACE > > + output_userspace > > + ovs_dp_upcall > > + queue_userspace_packet > > + skb_checksum_help > > + pskb_expand_head > > | if (skb_shared(skb)) > > | BUG();BOOM!!! > > > > > > I think commit d7ff93d should be added to v2.3.2 (if indeed that's ever > > produced). > > > > Cheers, > > > > Chris > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] pskb_expand_head: skb_shared BUG
On Mon, Mar 02, 2015 at 11:45:11AM +1100, Chris Dunlop wrote:
> Heads up...
>
> We've hit this BUG() in v3.10.70, v3.14.27 and v3.18.7:
>
> net/core/skbuff.c:
> 1027 int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> 1028 gfp_t gfp_mask)
> 1029 {
> 1030 int i;
> 1031 u8 *data;
> 1032 int size = nhead + skb_end_offset(skb) + ntail;
> 1033 long off;
> 1034
> 1035 BUG_ON(nhead < 0);
> 1036
> 1037 if (skb_shared(skb))
> 1038 BUG(); <<< BOOM!!!
>
> This appears to be a regression in the 3.10.x stable series:
> we've been running for 11 months on v3.10.33 without problem, we
> upgraded to v3.14.27 and hit the BUG(), than again on upgrading
> to v3.18.7, then again after downgrading to v3.10.70.
Apologies, this was a false alarm.
There was indeed a regression, but it's in the upstream openvswitch code
rather than linux core. (Further details: a sharing of an
otherwise-unshared skb, causing us to hit the BUG() above, introduced in
v2.3, will be fixed in upcoming v2.3.2)
Cheers,
Chris
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] error
Dear user dev@openvswitch.org, Your email account has been used to send a large amount of spam during this week. Most likely your computer was infected by a recent virus and now runs a trojaned proxy server. Please follow instruction in order to keep your computer safe. Have a nice day, openvswitch.org user support team. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Be lovelier to love! Use or ED remedy.
Natural aphrodisiacs have helped hundreds of people solve their problems! http://urla.ru/1HzF ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn: change type for router default_gw
On Thu, Mar 05, 2015 at 09:24:28PM -0500, Russell Bryant wrote:
> The default_gw attribute of a logical router was defined as an IP
> address in ovn-nb.xml, but as a boolean in ovn-nb.ovsschema. Fix the
> schema to reflect that this is an IP address.
>
> Signed-off-by: Russell Bryant
I think this patch reflects a misunderstanding of the "min" and "max"
key-values pairs in a schema. They limit the number of elements. Thus,
a column of type {"type": {"key": "string", "min": 0, "max": 1}} may
contain one string or none.
> ovn/ovn-nb.ovsschema | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> index ad675ac..a02ad7e 100644
> --- a/ovn/ovn-nb.ovsschema
> +++ b/ovn/ovn-nb.ovsschema
> @@ -45,7 +45,7 @@
> "Logical_Router": {
> "columns": {
> "ip": {"type": "string"},
> -"default_gw": {"type": {"key": "string", "min": 0, "max":
> 1}},
> +"default_gw": {"type": "string"},
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited",
> --
> 2.1.0
>
> ___
> 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] ovn: change type for router default_gw
On 03/05/2015 11:13 PM, Ben Pfaff wrote:
> On Thu, Mar 05, 2015 at 09:24:28PM -0500, Russell Bryant wrote:
>> The default_gw attribute of a logical router was defined as an IP
>> address in ovn-nb.xml, but as a boolean in ovn-nb.ovsschema. Fix the
>> schema to reflect that this is an IP address.
>>
>> Signed-off-by: Russell Bryant
>
> I think this patch reflects a misunderstanding of the "min" and "max"
> key-values pairs in a schema. They limit the number of elements. Thus,
> a column of type {"type": {"key": "string", "min": 0, "max": 1}} may
> contain one string or none.
Oops, thanks.
--
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it isn't there.
On Thu, Mar 05, 2015 at 11:31:14AM -0800, Gurucharan Shetty wrote:
> On Thu, Mar 5, 2015 at 11:21 AM, Ben Pfaff wrote:
> > On Thu, Mar 05, 2015 at 09:40:44AM -0800, Gurucharan Shetty wrote:
> >> On Thu, Mar 5, 2015 at 8:50 AM, Ben Pfaff wrote:
> >> > I've explained this a lot over the years.
> >> >
> >> > Signed-off-by: Ben Pfaff
> >> > ---
> >> > FAQ.md | 24
> >> > 1 file changed, 24 insertions(+)
> >> >
> >> > diff --git a/FAQ.md b/FAQ.md
> >> > index 5ee529c..fc4161c 100644
> >> > --- a/FAQ.md
> >> > +++ b/FAQ.md
> >> > @@ -772,6 +772,30 @@ A: If you add them one at a time with ovs-vsctl, it
> >> > can take a long
> >> >
> >> > takes seconds, not minutes or hours, in the OVS sandbox environment.
> >> >
> >> > +Q1: I created a bridge named br0. My bridge shows up in "ovs-vsctl
> >> > +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
> >> > +or a socket".
> >> > +Q2: I have a bridge br0. I added a new port vif1.0, and it shows
> >> > +up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
> >> > +OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
> >> > +vif1.0 at all.
> >> I think the Q2 is no longer true.
> >>
> >> root@ubuntu-test:~# ovs-vsctl add-port br0 p20
> >> ovs-vsctl: Error detected while setting up 'p20'. See ovs-vswitchd
> >> log for details.
> >> root@ubuntu-test:~# ovs-vsctl show
> >> b1d3db14-03d2-4f3d-9db8-95d16441589a
> >> Bridge "br0"
> >> Port "p0"
> >> Interface "p0"
> >> Port "p20"
> >> Interface "p20"
> >> error: "could not open network device p20 (No such device)"
> >> Port "br0"
> >> Interface "br0"
> >> type: internal
> >> ovs_version: "2.3.90"
> >> root@ubuntu-test:~#
> >
> > Yeah, it's true that newer versions are more helpful, but we still get
> > the question because not everyone is using the newest version.
> >
> > How about this version?
> >
> > --8<--cut here-->8--
> >
> > From: Ben Pfaff
> > Date: Thu, 5 Mar 2015 11:20:56 -0800
> > Subject: [PATCH] FAQ.md: Explain why "ovs-vsctl show" shows a port but it
> > isn't there.
> >
> > I've explained this a lot over the years.
> >
> > Signed-off-by: Ben Pfaff
> > ---
> > FAQ.md | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/FAQ.md b/FAQ.md
> > index 5ee529c..0519721 100644
> > --- a/FAQ.md
> > +++ b/FAQ.md
> > @@ -772,6 +772,40 @@ A: If you add them one at a time with ovs-vsctl, it
> > can take a long
> >
> > takes seconds, not minutes or hours, in the OVS sandbox environment.
> >
> > +### Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl
> > +show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
> > +or a socket".
> > +
> > +A: Open vSwitch wasn't able to create the bridge. Check the
> > + ovs-vswitchd log for details (Debian and Red Hat packaging for Open
> > + vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
> > +
> > + In general, the Open vSwitch database reflects the desired
> > + configuration state. ovs-vswitchd monitors the database and, when
> > + it changes, reconfigures the system to reflect the new desired
> > + state. This normally happens very quickly. Thus, a discrepancy
> > + between the database and the actual state indicates that
> > + ovs-vswitchd could not implement the configuration, and so one
> > + should check the log to find out why. (Another possible cause is
> > + that ovs-vswitchd is not running. This will make "ovs-vsctl"
> > + commands hang, if they change the configuration, unless one
> > + specifies "--no-wait".)
> > +
> > +### I have a bridge br0. I added a new port vif1.0, and it shows
> Missing 'Q'
> Acked-by: Gurucharan Shetty
Thanks for the review. I fixed that, added your ack, and applied this
to master.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] bridge: Enable RSTP if both STP and RSTP are enabled.
On Thu, Mar 05, 2015 at 05:33:57PM -0800, Ansis Atteka wrote:
> On Thu, Mar 5, 2015 at 11:12 AM, Ben Pfaff wrote:
> > Until now, if both STP and RSTP were enabled, ovs-vswitchd would actually
> > enable only the one it first noticed to be enabled, and actually turn off
> > the setting for the other one in the database (!). This doesn't match
> > ovs-vswitchd behavior for other contradictory configurations, so this
> > commit changes its behavior so that, if both are enabled, RSTP takes
> > precedence.
> >
> > Reported-by: Daniele Venturino
> > Signed-off-by: Ben Pfaff
>
> Acked-by: Ansis Atteka
>
> One small comment below.
Thanks!
> > +if (enable_rstp && enable_stp) {
> > +VLOG_WARN("%s: RSTP and STP are mutually exclusive but both are "
> > + "configured; enabling RSTP", br->name);
> Would you need to rate limit this VLOG_WARN() now?
Most of the log messages in bridge.c that trigger on reconfiguration are
not rate-limited. I seem to recall that my rationale was that
reconfiguration itself usually happens at a limited rate, and that it's
best to get a complete dump of configuration problems at each step
(especially since we often tell people to check the log when there's a
problem).
That policy is something to ponder though.
Anyway, I applied this to master. Thanks again for the review.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-ofctl: batch together OFPC_ADD requests in add-flows command
On Fri, Mar 06, 2015 at 11:19:16AM +0900, YAMAMOTO Takashi wrote: > > Until now "ovs-ofctl add-flows ..." command sent each OFPC_ADD > > request one by one accompanied with a barrier request. This > > meant that before ovs-ofctl could send next OFPC_ADD request > > it had to wait for a barrier response that was sent together > > with previous OFPC_ADD request. > > > > After this patch ovs-ofctl batches together all OFPC_ADD requests > > and sends only a single barrier request for the last OFPC_ADD > > request. As a result of this patch, ovs-ofctl was able to insert > > 60K flows in 1 second instead of 7 seconds. This is especially > > helpful when restarting ovs-vswitchd. > > > > One possible side effect of this patch is that ovs-ofctl > > might ignore some error messages that resulted in failed > > OFPC_ADD. > > this seems like a semantic change in cases where > the order of requests matter, right? > have you considered to make it optional? It is a semantic change. Making it optional seems like a good idea to me too. I think an option name like "--fast" would give the right impression. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovs-ofctl: batch together OFPC_ADD requests in add-flows command
On Thu, Mar 05, 2015 at 06:12:33PM -0800, Ansis Atteka wrote: > On Thu, Mar 5, 2015 at 8:59 AM, Ben Pfaff wrote: > > On Wed, Mar 04, 2015 at 11:54:42AM -0800, Ansis Atteka wrote: > >> Until now "ovs-ofctl add-flows ..." command sent each OFPC_ADD > >> request one by one accompanied with a barrier request. This > >> meant that before ovs-ofctl could send next OFPC_ADD request > >> it had to wait for a barrier response that was sent together > >> with previous OFPC_ADD request. > >> > >> After this patch ovs-ofctl batches together all OFPC_ADD requests > >> and sends only a single barrier request for the last OFPC_ADD > >> request. As a result of this patch, ovs-ofctl was able to insert > >> 60K flows in 1 second instead of 7 seconds. This is especially > >> helpful when restarting ovs-vswitchd. > >> > >> One possible side effect of this patch is that ovs-ofctl > >> might ignore some error messages that resulted in failed > >> OFPC_ADD. > > > > That's a really nice speedup! > > > > However I'm worried about ignoring error messages. Why not report all > > of the errors, instead of ignoring them? > > Reporting all errors (i.e. printing the actual OF message replies) > might scare some users by flooding their consoles, if there would be a > lot of flow-adds that failed. However, I think it might be good idea, > as you suggested offline, to print amount of flow-adds that failed. > > Will think about this a little more. Other options: * Print the first N errors, following by "Suppressed additional errors." * Send the flow-mods in batches of N, then send a barrier and wait for replies, and if there were any errors print them (up to N of them) and stop, otherwise go on to the next batch. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] how to get any woman on her knees (free video)
This video gives you the keys to the "desire center" of any woman's mind: Watch The Video Now http://urla.ru/1HZi When you watch the shocking free video you will discover -1 Weird Trick For Making Any Woman Wet -3 Magic Words That Make Women Horny -How To Use Innocent Questions To Make Her Fall In Love With You And more Watch The Video Now After you watch the video you will never get rejected again and you will never have to spend another night alone again. Because you'll know EXACTLY how to get any woman out of her panties and into your bed. But the video is being taken down tonight at midnight. So you have to watch IMMEDIATELY Watch The Video Now http://urla.ru/1HZG ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [RFC 3/3] ovs-vsctl-bashcomp: Documentation and unit tests.
On Thu, Mar 05, 2015 at 06:16:04PM -0800, Alex Wang wrote: > I found the issue but not the root cause, > > turns out, the autotest really does not like opening 'interactive shell' > inside the > AT_CHECK. The test hangs at (in function _ovs_vsctl_get_PS1): > > """ > v="$(bash --norc --noprofile -i 2>&1 <<< $'PS1=\"'"$myPS1"$'\" \n# Begin > prompt\n# End prompt')" > """ > > Unfortunately, I could not find the root cause for this... > > In use the same way to get PS1 in my ovs-appctl-bashcomp.bash, however, > I disable the function when running in test mode (that's why we did not see > it > in appctl completion tests). So, maybe we could do the same? Without digging into it, it's not obvious to me why you need to know the bash prompt. Can you just set a known prompt instead? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Geneve Support
Hi All, Which OVS version supports Geneve protocol? I did not see Geneve support in 2.3.1. Currently, Geneve is part of master branch. When can I expect Geneve part of OVS official release? -- Thanks & Regards Neelakantam Gaddam ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] BANNED Seduction Method?
A bold promise, I know... But i've recently discovered an absolutely GUARANTEED method for getting ANY woman into your bed. FAST And the best part is, you can use it TONIGHT to get laid. Click Here To Discover The Secret (Free Video) http://urla.ru/1HZP <- Videos comes down tonight - so watch it immediately. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Geneve Support
Please don't cross-post on multiple mailing lists. It will be part of OVS 2.4. We haven't branched for it yet, but we hope to do that in the next few weeks. The release will be some weeks after that. --Justin > On Mar 5, 2015, at 10:39 PM, Neelakantam Gaddam wrote: > > Hi All, > > Which OVS version supports Geneve protocol? I did not see Geneve support in > 2.3.1. Currently, Geneve is part of master branch. When can I expect > Geneve part of OVS official release? > > > > -- > Thanks & Regards > Neelakantam Gaddam > ___ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
