openvswitch_1.2.2-1_amd64.changes uploaded successfully to localhost
along with the files:
openvswitch_1.2.2-1.dsc
openvswitch_1.2.2.orig.tar.gz
openvswitch_1.2.2-1.debian.tar.gz
openvswitch-common_1.2.2-1_amd64.deb
openvswitch-switch_1.2.2-1_amd64.deb
openvswitch-ipsec_1.2.2-1_amd64.de
Accepted:
openvswitch-brcompat_1.2.2-1_amd64.deb
to main/o/openvswitch/openvswitch-brcompat_1.2.2-1_amd64.deb
openvswitch-common_1.2.2-1_amd64.deb
to main/o/openvswitch/openvswitch-common_1.2.2-1_amd64.deb
openvswitch-controller_1.2.2-1_amd64.deb
to main/o/openvswitch/openvswitch-controlle
Your message dated Wed, 26 Oct 2011 07:32:51 +
with message-id
and subject line Bug#642206: fixed in openvswitch 1.2.2-1
has caused the Debian Bug report #642206,
regarding Wrong path to executable in /etc/init.d/openvswitch-controller
to be marked as done.
This means that you claim that the
openvswitch_1.2.2-2_amd64.changes uploaded successfully to localhost
along with the files:
openvswitch_1.2.2-2.dsc
openvswitch_1.2.2-2.debian.tar.gz
openvswitch-common_1.2.2-2_amd64.deb
openvswitch-switch_1.2.2-2_amd64.deb
openvswitch-ipsec_1.2.2-2_amd64.deb
openvswitch-controller_1.2.2
Accepted:
openvswitch-brcompat_1.2.2-2_amd64.deb
to main/o/openvswitch/openvswitch-brcompat_1.2.2-2_amd64.deb
openvswitch-common_1.2.2-2_amd64.deb
to main/o/openvswitch/openvswitch-common_1.2.2-2_amd64.deb
openvswitch-controller_1.2.2-2_amd64.deb
to main/o/openvswitch/openvswitch-controlle
This series of patches essentially rewrites the OFPP_NORMAL
implementation, improving its performance and eliminating some
ofproto-dpif.c. It's an intermediate step toward adding some
more mirroring features.
Ben Pfaff (13):
ofproto-dpif: Do not output RSPAN packets to SPAN ports.
ofproto-dpi
It's always been my intention that ports used as port mirroring
destinations (SPAN) be reserved solely for that purpose. When SPAN and
RSPAN are both configured, however, RSPAN mirror packets could get directed
to SPAN ports, which was unintentional.
This commit also updates the documentation to
flow_get_vlan() duplicated the logic in input_vid_to_vlan() in an
unclear way and added some logic of its own to detect invalid
input VLANs. This commit eliminates the duplication and makes the
code easier to understand.
---
ofproto/ofproto-dpif.c | 105 +++---
I came close to add a "continue;" inside the main "while" loop in
compose_mirror_dsts(), which would have turned it into an infinite loop.
This commit changes it to a "for" loop that is harder to screw up.
---
ofproto/ofproto-dpif.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
dif
This code previously checked whether each individual mirror output was
already in the set of destinations. This is O(n**2) in the number of
ports in a bridge.
The new code uses a smarter algorithm to eliminate duplicates, one that is
O(n) in the number of ports in a bridge.
---
ofproto/ofproto-d
I like the _3way suffix convention. It makes the interpretation of the
return value clear. We use it elsewhere in the tree, so use it here too.
There weren't any users of flow_compare() outside of flow.h, but there soon
will be.
---
lib/flow.h |6 +++---
1 files changed, 3 insertions(+), 3
This will acquire a user in an upcoming commit that uses it in parsing
without modifying the text being parsed or copying it.
---
lib/shash.c | 25 ++---
lib/shash.h |3 ++-
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/lib/shash.c b/lib/shash.c
index 32
---
lib/odp-util.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 33672c8..1f6f33d 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -33,8 +33,7 @@
#include "timeval.h"
#include "util.h"
-static void
-format_odp_key_attr(c
This seems like a worthwhile improvement in itself, but it will also see
additional users in upcoming commits.
---
lib/odp-util.c | 40 +++-
1 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 1f6f33d..9959662
An upcoming patch to odp-util will add a new user, but this seems like a
reasonable change in any case.
---
lib/odp-util.c | 22 ++
lib/odp-util.h |3 +++
ofproto/ofproto-dpif.c |9 +
3 files changed, 26 insertions(+), 8 deletions(-)
diff --gi
Really the "trace" command should support this but in fact I need it for
an upcoming update to a test.
---
lib/odp-util.c | 29 ++---
lib/odp-util.h |4 +++-
ofproto/ofproto-dpif.c |2 +-
tests/test-odp.c |2 +-
4 files changed, 31 insert
An upcoming commit will add a user. The only planned users for now are
part of unit tests themselves, so it doesn't seem important to unit test
it.
---
lib/odp-util.c| 255 -
lib/odp-util.h|3 +
utilities/ovs-dpctl.c | 29
The compare-odp-actions.pl utility isn't fully general, even for its
intended purpose of allowing sets of ODP actions to be compared
ignoring unimportant differences in ordering of output actions and
VLAN set actions. I decided that the proper way to do it was to have
a utility that can actually p
struct dst is an intermediate form for OFPP_NORMAL translation that
has existed since the beginning of Open vSwitch development. It
has always been a bit ugly, since ideally we wouldn't need any intermediate
form at all. This commit eliminates it, which speeds up OFPP_NORMAL
translation.
struct
Following patch adds skb-priority to flow key. So userspace will know
what was priority when packet arrived and we can remove the pop/reset
priority action. It's no longer necessary to have a special action for
pop that is based on the kernel remembering original skb->priority.
Userspace can just e
This can cause ovs-vswitchd to crash.
Bug #8007.
Reported-by: Krishna Miriyala
---
vswitchd/bridge.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 3a19235..09696d5 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/br
As an aside. This particular issue has bitten us several times. Does
it make sense in the future to push the check for synthetic ifaces
into the idl?
Ethan
On Wed, Oct 26, 2011 at 11:42, Ethan Jackson wrote:
> This can cause ovs-vswitchd to crash.
>
> Bug #8007.
> Reported-by: Krishna Miriyala
On Wed, Oct 26, 2011 at 11:42:11AM -0700, Ethan Jackson wrote:
> This can cause ovs-vswitchd to crash.
>
> Bug #8007.
> Reported-by: Krishna Miriyala
The fix looks good in isolation. Did you look around to see whether
any other code needs a similar fix?
Thanks,
Ben.
__
Hmm, that sounds like a good idea, yes.
On Wed, Oct 26, 2011 at 11:42:57AM -0700, Ethan Jackson wrote:
> As an aside. This particular issue has bitten us several times. Does
> it make sense in the future to push the check for synthetic ifaces
> into the idl?
>
> Ethan
>
> On Wed, Oct 26, 2011
I gave it a once over and nothing in particular stands out. This is
the only function which writes to the port table in this way so I
think we're good.
Thanks for the review.
Ethan
On Wed, Oct 26, 2011 at 11:42, Ben Pfaff wrote:
> On Wed, Oct 26, 2011 at 11:42:11AM -0700, Ethan Jackson wrote:
>
OK, great, thanks.
On Wed, Oct 26, 2011 at 11:50:03AM -0700, Ethan Jackson wrote:
> I gave it a once over and nothing in particular stands out. This is
> the only function which writes to the port table in this way so I
> think we're good.
>
> Thanks for the review.
> Ethan
>
> On Wed, Oct 26,
Navindra Yadav pointed out in a discussion over on an ONF issue tracker
that first/later fragment isn't as useful with IPv6: the TCP/UDP port
numbers aren't necessarily in the first fragment, because other
intermediate extension headers can follow the fragment header.
Any idea what we should do ab
This is actually intended for use by the VXLAN tunnel implementation, which
should use a source port range, but it is fairly generic infrastructure so
this implements it independent of VXLAN and applies it to CAPWAP.
Not yet tested.
---
datapath/tunnel.c| 184
On Wed, Oct 26, 2011 at 2:59 PM, Ben Pfaff wrote:
> Navindra Yadav pointed out in a discussion over on an ONF issue tracker
> that first/later fragment isn't as useful with IPv6: the TCP/UDP port
> numbers aren't necessarily in the first fragment, because other
> intermediate extension headers can
On Wed, Oct 26, 2011 at 03:34:10PM -0700, Jesse Gross wrote:
> On Wed, Oct 26, 2011 at 2:59 PM, Ben Pfaff wrote:
> > Navindra Yadav pointed out in a discussion over on an ONF issue tracker
> > that first/later fragment isn't as useful with IPv6: the TCP/UDP port
> > numbers aren't necessarily in t
Synthetic rows lack a lot of important metadata that the IDL adds to rows
actually obtained from the database, and it's impractical to add that
metadata to synthetic rows. This means that the IDL functions to modify
these rows dereference null pointers and segfault. So, it's really
important not
Wouldn't we want to remove all of the synthetic checks from the bridge
as well? I haven't looked at this closely yet.
Ethan
On Wed, Oct 26, 2011 at 15:47, Ben Pfaff wrote:
> Synthetic rows lack a lot of important metadata that the IDL adds to rows
> actually obtained from the database, and it's
That's now possible but not necessary. It could be added as a followup
at any time.
It's more important to actually make mistakes not blow up.
On Wed, Oct 26, 2011 at 03:49:33PM -0700, Ethan Jackson wrote:
> Wouldn't we want to remove all of the synthetic checks from the bridge
> as well? I hav
On Wed, Oct 26, 2011 at 3:36 PM, Ben Pfaff wrote:
> On Wed, Oct 26, 2011 at 03:34:10PM -0700, Jesse Gross wrote:
>> On Wed, Oct 26, 2011 at 2:59 PM, Ben Pfaff wrote:
>> > Navindra Yadav pointed out in a discussion over on an ONF issue tracker
>> > that first/later fragment isn't as useful with IP
I'm dropping this patch because test-openflowd has been deleted.
On Fri, Oct 21, 2011 at 06:44:09PM -0700, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Thu, Aug 25, 2011 at 12:34, Ben Pfaff wrote:
> > The manpage name is test-openflowd.8, not ovs-openflowd.8.
> >
> > This should have cau
I'm dropping this patch because test-openflowd has been deleted.
On Fri, Oct 21, 2011 at 06:44:49PM -0700, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Thu, Aug 25, 2011 at 12:34, Ben Pfaff wrote:
> > The warning is:
> > ? ? ? ?tests/test-openflowd.8:365: warning: macro `DD' not defined
On Wed, Oct 26, 2011 at 03:53:49PM -0700, Jesse Gross wrote:
> On Wed, Oct 26, 2011 at 3:36 PM, Ben Pfaff wrote:
> > On Wed, Oct 26, 2011 at 03:34:10PM -0700, Jesse Gross wrote:
> >> On Wed, Oct 26, 2011 at 2:59 PM, Ben Pfaff wrote:
> >> > Navindra Yadav pointed out in a discussion over on an ONF
On Fri, Oct 21, 2011 at 06:42:00PM -0700, Ethan Jackson wrote:
> Should sodepends.pl be copyright 2008, 2011 as well as 2011?
It's derived from soexpand.pl which has a 2008 copyright, so my
(imperfect) understanding of the rules is that the earlier copyright
year should be retained.
> I think the
> This is nastier than it looks at first. Automake is what does the
> include processing here (take a look at the generated Makefile in your
> build directory: it won't have any include directive from this).
> Automake will error out if an include file is missing. That means that
> we need to inc
On Wed, Oct 26, 2011 at 04:10:14PM -0700, Ethan Jackson wrote:
> > This is nastier than it looks at first. ?Automake is what does the
> > include processing here (take a look at the generated Makefile in your
> > build directory: it won't have any include directive from this).
> > Automake will err
This patch special cases OFPP_NONE to be always up in bundle
actions. Presumably, if a controller put OFPP_NONE in their bundle
action, they want it to be an available choice.
---
ofproto/ofproto-dpif.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ofproto/ofproto-dpif.
The OFPP_LOCAL port is a real port with a carrier status. There
isn't a good reason to ignore this data when implementing the
bundle action.
---
ofproto/ofproto-dpif.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 39
On Wed, Oct 26, 2011 at 04:14:48PM -0700, Ethan Jackson wrote:
> This patch special cases OFPP_NONE to be always up in bundle
> actions. Presumably, if a controller put OFPP_NONE in their bundle
> action, they want it to be an available choice.
Seems reasonable but I'd update nicira-ext.h to ment
On Wed, Oct 26, 2011 at 04:14:49PM -0700, Ethan Jackson wrote:
> The OFPP_LOCAL port is a real port with a carrier status. There
> isn't a good reason to ignore this data when implementing the
> bundle action.
Looks good to me.
___
dev mailing list
dev@
On Wed, Oct 26, 2011 at 04:10:10PM -0700, Ben Pfaff wrote:
> On Wed, Oct 26, 2011 at 04:10:14PM -0700, Ethan Jackson wrote:
> > > This is nastier than it looks at first. ?Automake is what does the
> > > include processing here (take a look at the generated Makefile in your
> > > build directory: it
This patch special cases OFPP_NONE to be always up in bundle
actions. Presumably, if a controller put OFPP_NONE in their bundle
action, they want it to be an available choice.
This patch also adds documentation to the bundle action about slave
liveness.
---
include/openflow/nicira-ext.h |7 +
Looks good to me.
I didn't check that everywhere that needs to change did in-fact change.
In the next couple of days, I'm going to write a patch which removes
all of the synthetic checks from the bridge.
Ethan
On Wed, Oct 26, 2011 at 15:47, Ben Pfaff wrote:
> Synthetic rows lack a lot of impor
We can help you with the urgent loan you need. get back to us with the
below info if interested.
Name..
Country...
Loan amount needed..
Loan Duration.
Thanks
Nosotros le podemos ayudar con el préstamo de urgencia que necesita. Para
regresar a nosotros con la información siguien
On Wed, Oct 26, 2011 at 04:37:46PM -0700, Ethan Jackson wrote:
> This patch special cases OFPP_NONE to be always up in bundle
> actions. Presumably, if a controller put OFPP_NONE in their bundle
> action, they want it to be an available choice.
>
> This patch also adds documentation to the bundle
On Wed, Oct 26, 2011 at 11:32 AM, Pravin B Shelar wrote:
> diff --git a/datapath/datapath.c b/datapath/datapath.c
> index be90d54..4809d4b 100644
> --- a/datapath/datapath.c
> +++ b/datapath/datapath.c
> @@ -770,7 +764,8 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb,
> struct genl_info
The ovs-monitor-ipsec test waits for a specific number of lines
of output before doing a comparison to the correct values. However,
some copy and pasted code did not update the number of lines to
look for resulting in a race condition where the comparison could
happen before the script finished ru
On Wed, Oct 26, 2011 at 09:19:20PM -0700, Jesse Gross wrote:
> The ovs-monitor-ipsec test waits for a specific number of lines
> of output before doing a comparison to the correct values. However,
> some copy and pasted code did not update the number of lines to
> look for resulting in a race cond
On Wed, Oct 26, 2011 at 9:23 PM, Ben Pfaff wrote:
> On Wed, Oct 26, 2011 at 09:19:20PM -0700, Jesse Gross wrote:
>> The ovs-monitor-ipsec test waits for a specific number of lines
>> of output before doing a comparison to the correct values. However,
>> some copy and pasted code did not update th
I'm not square. Go for it, man!
--Justin
On Oct 26, 2011, at 10:09 AM, Ben Pfaff wrote:
> I like the _3way suffix convention. It makes the interpretation of the
> return value clear. We use it elsewhere in the tree, so use it here too.
>
> There weren't any users of flow_compare() outside o
54 matches
Mail list logo
