> How much work would it be to fix all the remaining pychecker and pep8
> warnings in one series? I think I'd rather get it all fixed in one go,
> if it's practical.
Probably a good idea. I was fixing up files that I had been touching
in a series I'm about to send out. I'll see how much work it
This series has gone without any reviews for a couple of weeks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
This series has been waiting for review for almost a month now.
I'd like to get it reviewed someday soon.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Thanks, I pushed it.
On Fri, Sep 23, 2011 at 09:22:39PM -0700, Justin Pettit wrote:
> Looks obviously correct.
>
> --Justin
>
>
> On Sep 23, 2011, at 5:14 PM, Ben Pfaff wrote:
>
> > ---
> > lib/bond.c |1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/lib/bon
Looks obviously correct.
--Justin
On Sep 23, 2011, at 5:14 PM, Ben Pfaff wrote:
> ---
> lib/bond.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/lib/bond.c b/lib/bond.c
> index 5b984fb..e15af04 100644
> --- a/lib/bond.c
> +++ b/lib/bond.c
> @@ -639,7 +639,6 @@
These look fine to me.
They're going to conflict with the unit tests I sent out today, but it
should be easy enough to fix up.
How much work would it be to fix all the remaining pychecker and pep8
warnings in one series? I think I'd rather get it all fixed in one go,
if it's practical.
_
On Fri, Sep 23, 2011 at 5:17 PM, Ben Pfaff wrote:
> compose_actions(), which is part of the OFPP_NORMAL implementation, had
> multiple flaws that this commit corrects.
>
> First, it did not commit changes made to the flow by actions preceding
> the output to OFPP_NORMAL. This means that, for exam
Looks obviously correct, though you might want to fix
"Map from interface name to "
while you're there
On Fri, Sep 23, 2011 at 5:21 PM, Ethan Jackson wrote:
> Pleases pep8.
> ---
> .../usr_share_openvswitch_scripts_ovs-xapi-sync| 30
>
> 1 files changed, 24 insert
Pleases pep8.
---
.../usr_share_openvswitch_scripts_ovs-xapi-sync| 30
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync
b/xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync
index b2d9358..7b61e25 10
Found by pychecker.
---
.../usr_share_openvswitch_scripts_ovs-xapi-sync|5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync
b/xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync
index 91ada47..b2d9358 100755
--- a
On Fri, Sep 23, 2011 at 10:57:35AM -0700, Ben Pfaff wrote:
> [adding Ethan since he designed the 'base_flow' thingy]
>
> On Thu, Sep 22, 2011 at 05:18:30PM -0700, Pravin Shelar wrote:
> > Track vlan-id correctly. So that we can use that information for
> > composing optimized action set.
>
>
Significant updates by Ben Pfaff, including:
* Comment, coding style, indentation updates.
* Documentation improved.
* Added tests.
* Dropped PORT_VLAN_EMPTY.
---
NEWS |3 +
ofproto/ofproto-dpif.c | 156 +++---
ofproto/ofproto.h
---
lib/bitmap.c | 21 -
lib/bitmap.h |2 ++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index df3c4eb..76a667a 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, 2009 Nicira Networks.
+
These tests would have caught the bug fixed in the previous commit
"ofproto-dpif: Fix behavior when a subset of VLANs is trunked."
---
tests/ofproto-dpif.at | 79 +++
tests/ofproto-macros.at | 43 +
2 files changed, 122 inse
OFP_VLAN_NONE used to be convenient as a value for struct dst's 'vlan'
member, because it ended up being used in actions anyway, but now it's
much better to just use 0.
---
ofproto/ofproto-dpif.c | 55 ++-
1 files changed, 21 insertions(+), 34 deletion
This second version of the "vlans" series adds two commits at the
beginning that fix up some internal ugliness and bugs in the OFPP_NORMAL
handling of vlans in ofproto-dpif. I've also fixed how mirroring to
VLANs works in the final commit, as well as increasing the stringency
of the tests to ensur
compose_actions(), which is part of the OFPP_NORMAL implementation, had
multiple flaws that this commit corrects.
First, it did not commit changes made to the flow by actions preceding
the output to OFPP_NORMAL. This means that, for example, if an OpenFlow
action to modify an L2 or L3 header prec
Will do, thanks.
On Fri, Sep 23, 2011 at 05:15:22PM -0700, Ethan Jackson wrote:
> Sounds good.
>
> pep8 complained about the global variable being defined outside module
> context which is why I deleted it. Could you please fix the warning
> in your patch?
>
> Ethan
>
> On Fri, Sep 23, 2011 at
Sounds good.
pep8 complained about the global variable being defined outside module
context which is why I deleted it. Could you please fix the warning
in your patch?
Ethan
On Fri, Sep 23, 2011 at 17:13, Ben Pfaff wrote:
> This option gets used in the unit test for ovs-monitor-ipsec that is
>
---
lib/bond.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/bond.c b/lib/bond.c
index 5b984fb..e15af04 100644
--- a/lib/bond.c
+++ b/lib/bond.c
@@ -639,7 +639,6 @@ void
bond_account(struct bond *bond, const struct flow *flow, uint16_t vlan,
uint64_t n
On Fri, Sep 23, 2011 at 05:05:56PM -0700, Ethan Jackson wrote:
> Pleases pep8.
Fine with me.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
This option gets used in the unit test for ovs-monitor-ipsec that is
currently out for review. I accidentally let part of that stray into
the wrong commit. It's fine if you delete it, though; I'll fold it
into the unit test commit.
___
dev mailing list
Pleases pep8.
---
debian/ovs-monitor-ipsec | 42 --
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/debian/ovs-monitor-ipsec b/debian/ovs-monitor-ipsec
index f62c393..10b278d 100755
--- a/debian/ovs-monitor-ipsec
+++ b/debian/ovs-monitor-i
---
debian/ovs-monitor-ipsec |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/debian/ovs-monitor-ipsec b/debian/ovs-monitor-ipsec
index c123188..f62c393 100755
--- a/debian/ovs-monitor-ipsec
+++ b/debian/ovs-monitor-ipsec
@@ -436,7 +436,7 @@ def get_ssl_cert(data):
def
On Fri, Sep 23, 2011 at 03:44:49PM -0700, Jesse Gross wrote:
> On Fri, Sep 23, 2011 at 3:32 PM, Ben Pfaff wrote:
> > There's only a small race window on datapath creation when get_dpfindex()
> > can return 0, so it's pretty unlikely.
> >
> > Found by inspection.
> >
> > Signed-off-by: Ben Pfaff
>
On Fri, Sep 23, 2011 at 3:32 PM, Ben Pfaff wrote:
> There's only a small race window on datapath creation when get_dpfindex()
> can return 0, so it's pretty unlikely.
>
> Found by inspection.
>
> Signed-off-by: Ben Pfaff
In general, I haven't been putting likely/unlikely in the upcall path
becau
On Sep 23, 2011, at 3:35 PM, Ben Pfaff wrote:
> On Fri, Sep 23, 2011 at 03:32:31PM -0700, Justin Pettit wrote:
>> cmd_output(CAP_NETWORK_STATUS,
>> - [OVS_APPCTL, '-t',
>> '/var/run/ovs-vswitchd.%s.ctl' % vspid, '-e' 'bond/show %s' % b],
>> +
On Fri, Sep 23, 2011 at 03:32:31PM -0700, Justin Pettit wrote:
> cmd_output(CAP_NETWORK_STATUS,
> - [OVS_APPCTL, '-t', '/var/run/ovs-vswitchd.%s.ctl'
> % vspid, '-e' 'bond/show %s' % b],
> + [OVS_APPCTL, '-t', '@RUNDIR@/ovs-vswit
There's only a small race window on datapath creation when get_dpfindex()
can return 0, so it's pretty unlikely.
Found by inspection.
Signed-off-by: Ben Pfaff
---
datapath/datapath.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datap
---
utilities/bugtool/ovs-bugtool.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/ovs-bugtool.in
index c2b603f..422b2dd 100755
--- a/utilities/bugtool/ovs-bugtool.in
+++ b/utilities/bugtool/ovs-bugtool.in
@@ -599,7
On Fri, Sep 23, 2011 at 3:25 PM, Ben Pfaff wrote:
> On Fri, Sep 23, 2011 at 03:24:47PM -0700, Jesse Gross wrote:
>> On Fri, Sep 23, 2011 at 2:53 PM, Ben Pfaff wrote:
>> > On Fri, Sep 23, 2011 at 02:20:17PM -0700, Jesse Gross wrote:
>> >> Currently it is possible for a client on a single port to g
Thanks, pushed.
Ethan
On Fri, Sep 23, 2011 at 15:26, Ben Pfaff wrote:
> On Fri, Sep 23, 2011 at 03:24:49PM -0700, Ethan Jackson wrote:
>> Pleases pep8.
>
> Looks good.
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/d
Thanks, pushed.
On Fri, Sep 23, 2011 at 15:23, Ben Pfaff wrote:
> Looks good.
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, Sep 23, 2011 at 03:24:49PM -0700, Ethan Jackson wrote:
> Pleases pep8.
Looks good.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, Sep 23, 2011 at 03:24:47PM -0700, Jesse Gross wrote:
> On Fri, Sep 23, 2011 at 2:53 PM, Ben Pfaff wrote:
> > On Fri, Sep 23, 2011 at 02:20:17PM -0700, Jesse Gross wrote:
> >> Currently it is possible for a client on a single port to generate
> >> a huge number of packets that miss in the k
On Fri, Sep 23, 2011 at 2:53 PM, Ben Pfaff wrote:
> On Fri, Sep 23, 2011 at 02:20:17PM -0700, Jesse Gross wrote:
>> Currently it is possible for a client on a single port to generate
>> a huge number of packets that miss in the kernel flow table and
>> monopolize the userspace/kernel communication
Pleases pep8.
---
tests/test-jsonrpc.py | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/test-jsonrpc.py b/tests/test-jsonrpc.py
index fda9a03..781f1f4 100644
--- a/tests/test-jsonrpc.py
+++ b/tests/test-jsonrpc.py
@@ -23,6 +23,7 @@ import ovs.jsonrpc
i
On Fri, Sep 23, 2011 at 03:22:32PM -0700, Jesse Gross wrote:
> On Fri, Sep 23, 2011 at 2:38 PM, Ben Pfaff wrote:
> > On Fri, Sep 23, 2011 at 02:20:13PM -0700, Jesse Gross wrote:
> >> Currently we publish several multicast groups for upcalls and let
> >> userspace sockets subscribe to them. ??The b
Looks good.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, Sep 23, 2011 at 2:38 PM, Ben Pfaff wrote:
> On Fri, Sep 23, 2011 at 02:20:13PM -0700, Jesse Gross wrote:
>> Currently we publish several multicast groups for upcalls and let
>> userspace sockets subscribe to them. The benefit of this is mostly
>> that userspace is the one doing the subscr
---
tests/test-jsonrpc.py |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/test-jsonrpc.py b/tests/test-jsonrpc.py
index 064457e..fda9a03 100644
--- a/tests/test-jsonrpc.py
+++ b/tests/test-jsonrpc.py
@@ -177,7 +177,7 @@ def main(argv):
args = args[1:]
Thanks, pushed.
On Fri, Sep 23, 2011 at 03:18:33PM -0700, Ethan Jackson wrote:
> Looks good,
>
> Ethan
>
> On Fri, Sep 23, 2011 at 15:15, Ben Pfaff wrote:
> > ---
> > ?lib/tag.h | ? ?2 +-
> > ?1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/lib/tag.h b/lib/tag.h
> > index
Looks good,
Ethan
On Fri, Sep 23, 2011 at 15:15, Ben Pfaff wrote:
> ---
> lib/tag.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/tag.h b/lib/tag.h
> index 5885e15..9cb581d 100644
> --- a/lib/tag.h
> +++ b/lib/tag.h
> @@ -75,7 +75,7 @@ static inline bool tag
---
lib/tag.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/tag.h b/lib/tag.h
index 5885e15..9cb581d 100644
--- a/lib/tag.h
+++ b/lib/tag.h
@@ -75,7 +75,7 @@ static inline bool tag_intersects(tag_type, tag_type);
static inline bool tag_is_valid(tag_type);
/* Ret
On Fri, Sep 23, 2011 at 02:20:17PM -0700, Jesse Gross wrote:
> Currently it is possible for a client on a single port to generate
> a huge number of packets that miss in the kernel flow table and
> monopolize the userspace/kernel communication path. This
> effectively DoS's the machine because no
On Fri, Sep 23, 2011 at 02:20:16PM -0700, Jesse Gross wrote:
> Many of our functions pass around a pointer to Netlink attributes
> and a length. This exposes the version of nl_attr_find that takes
> that format so it can be used by callers outside the Netlink library.
> ---
> v2: New patch.
Looks
On Fri, Sep 23, 2011 at 02:20:15PM -0700, Jesse Gross wrote:
> Each time we run through the poll loop, we check all file descriptors
> that we were waiting on to see if there is data available. However,
> this requires a system call and poll already provides information on
> which FDs caused the w
On Fri, Sep 23, 2011 at 02:20:13PM -0700, Jesse Gross wrote:
> Currently we publish several multicast groups for upcalls and let
> userspace sockets subscribe to them. The benefit of this is mostly
> that userspace is the one doing the subscription - the actual
> multicast capability is not curren
Awesome, thanks.
Ethan
On Fri, Sep 23, 2011 at 14:25, Ben Pfaff wrote:
> I pushed this series and sent out two more patches that add
> unit tests.
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
__
I pushed this series and sent out two more patches that add
unit tests.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
---
debian/ovs-monitor-ipsec | 52 ++-
tests/automake.mk |1 +
tests/ovs-monitor-ipsec.at | 222
tests/testsuite.at |1 +
4 files changed, 254 insertions(+), 22 deletions(-)
create mode 100644 tests/ovs-monitor-ips
---
tests/MockXenAPI.py| 82
tests/automake.mk |4 +-
tests/ovs-xapi-sync.at | 74 ++
tests/testsuite.at |1 +
.../usr_share
Currently it is possible for a client on a single port to generate
a huge number of packets that miss in the kernel flow table and
monopolize the userspace/kernel communication path. This
effectively DoS's the machine because no new flow setups can take
place. This adds some additional fairness b
Many of our functions pass around a pointer to Netlink attributes
and a length. This exposes the version of nl_attr_find that takes
that format so it can be used by callers outside the Netlink library.
---
v2: New patch.
---
lib/netlink.c |2 +-
lib/netlink.h |2 ++
2 files changed, 3 ins
Each time we run through the poll loop, we check all file descriptors
that we were waiting on to see if there is data available. However,
this requires a system call and poll already provides information on
which FDs caused the wakeup so it is inefficient as the number of
active FDs grows. This p
Now that upcalls from the kernel use unicast sockets, we need to
tell the kernel where to send them explicitly. This means that
when the switch is restarted it's necessary to take control of any
existing objects, which is done when the dpif listen mask becomes
non-zero. Since we're going to blow
Currently we publish several multicast groups for upcalls and let
userspace sockets subscribe to them. The benefit of this is mostly
that userspace is the one doing the subscription - the actual
multicast capability is not currently used and probably wouldn't be
even if we moved to a multiprocess
In the future, the kernel will use unicast messages instead of
multicast to send upcalls. As a result, we need to be able to
tell it where to direct the traffic. This adds a function to expose
the Netlink pid of a socket so it can be included in messages to the
kernel.
---
v2: Unchanged.
---
lib
On Fri, Sep 23, 2011 at 11:04:43AM -0700, Jesse Gross wrote:
> On Fri, Sep 23, 2011 at 9:16 AM, Ben Pfaff wrote:
> > On Thu, Sep 22, 2011 at 03:59:30PM -0700, Jesse Gross wrote:
> >> On Thu, Sep 22, 2011 at 1:11 PM, Ben Pfaff wrote:
> >> > On Mon, Sep 19, 2011 at 03:00:08PM -0700, Jesse Gross wro
On Fri, Sep 23, 2011 at 9:16 AM, Ben Pfaff wrote:
> On Thu, Sep 22, 2011 at 03:59:30PM -0700, Jesse Gross wrote:
>> On Thu, Sep 22, 2011 at 1:11 PM, Ben Pfaff wrote:
>> > On Mon, Sep 19, 2011 at 03:00:08PM -0700, Jesse Gross wrote:
>> >> Currently it is possible for a client on a single port to g
[adding Ethan since he designed the 'base_flow' thingy]
On Thu, Sep 22, 2011 at 05:18:30PM -0700, Pravin Shelar wrote:
> Track vlan-id correctly. So that we can use that information for
> composing optimized action set.
I don't think that this is a sufficient fix. The problem remains, at
le
On Thu, Sep 22, 2011 at 03:59:30PM -0700, Jesse Gross wrote:
> On Thu, Sep 22, 2011 at 1:11 PM, Ben Pfaff wrote:
> > On Mon, Sep 19, 2011 at 03:00:08PM -0700, Jesse Gross wrote:
> >> Currently it is possible for a client on a single port to generate
> >> a huge number of packets that miss in the k
Thanks, I pushed it.
Yeah, yesterday was OK.
On Thu, Sep 22, 2011 at 05:52:46PM -0700, Justin Pettit wrote:
> Looks good.
>
> (Based on our conversation earlier, I guess this is a good day, so
> you didn't just push it.)
>
> --Justin
>
>
> On Sep 22, 2011, at 5:12 PM, Ben Pfaff wrote:
>
> >
On Fri, Sep 23, 2011 at 08:11:18PM +0900, Simon Horman wrote:
> this series contains a second round of patches intended to bring Open
> vSwitch closer to being able to be compiled when compiling using the
> Android NDK r6b (Android API level 13).
Thanks Simon, I pushed both of these to "master".
_
Attention,
It was resolved and agreed at the bank head quarter that your
inheritance fund would be deliver to you on a special method of payment Tag
name read swift credit card, forward to us your full information to enable us
deliver your card to you.
Mr.S.general Okom
__
Hi,
this series contains a second round of patches intended to bring Open
vSwitch closer to being able to be compiled when compiling using the
Android NDK r6b (Android API level 13).
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailma
This appears to be required when building using the Android NDK r6b
(Android API level 13).
---
utilities/ovs-vlan-bug-workaround.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/utilities/ovs-vlan-bug-workaround.c
b/utilities/ovs-vlan-bug-workaround.c
index 9722c27..f45
This appears to be required when building using the Android NDK r6b
(Android API level 13).
---
vswitchd/ovs-brcompatd.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/vswitchd/ovs-brcompatd.c b/vswitchd/ovs-brcompatd.c
index 3cb1cfc..41aabe4 100644
--- a/vswitchd/ovs-brc
On Sep 22, 2011, at 7:34 PM, Ben Pfaff wrote:
> On Thu, Sep 22, 2011 at 06:15:41PM -0700, Justin Pettit wrote:
>> .IP "\fBshow\-log\fI db\fR"
>> -Prints a summary of the records in \fBdb\fR's log, including the time
>> +Prints a summary of the records in \fIdb\fR's log, including the time
>> and d
69 matches
Mail list logo
