Thanks for the review, I incorporated your comments and pushed this.
Ethan
On Fri, Jul 22, 2011 at 15:45, Ben Pfaff wrote:
> On Fri, Jul 22, 2011 at 01:36:26PM -0700, Ethan Jackson wrote:
>> The mac-learning implementation used a free list to keep track of
>> statically allocated table entries.
Hey, it's not trailing whitespace anymore if @&t@ is after it.
On Fri, Jul 22, 2011 at 04:03:24PM -0700, Ethan Jackson wrote:
> Yep, trailing whitespace. You know how I feel about that =).
>
> Ethan
>
> On Fri, Jul 22, 2011 at 15:55, Ben Pfaff wrote:
> > On Fri, Jul 22, 2011 at 03:54:03PM -070
Oh, I forgot to remove the warnings from the callers. I'll do that
before merging.
Ethan
On Fri, Jul 22, 2011 at 15:46, Ben Pfaff wrote:
> That's what I had in mind, thanks.
>
> On Fri, Jul 22, 2011 at 03:44:18PM -0700, Ethan Jackson wrote:
>> Here is an incremental based on comments on a futur
Yep, trailing whitespace. You know how I feel about that =).
Ethan
On Fri, Jul 22, 2011 at 15:55, Ben Pfaff wrote:
> On Fri, Jul 22, 2011 at 03:54:03PM -0700, Ethan Jackson wrote:
>> Sounds good, here is an incremental. I had to slightly modify test-bundle.c.
>
> OK. Looks like trailing white
On Fri, Jul 22, 2011 at 03:58:44PM -0700, Ethan Jackson wrote:
> > The update to the comment on nx_action_multipath could have gone into
> > the commit that generalized the multipath action output choices.
>
> Ooops, simple rebasing error.
>
> > The comment on the 'dst' member of nx_action_bundle
> The update to the comment on nx_action_multipath could have gone into
> the commit that generalized the multipath action output choices.
Ooops, simple rebasing error.
> The comment on the 'dst' member of nx_action_bundle says that it is a
> register, but that's not required, right?
I'll fix th
On Fri, Jul 22, 2011 at 03:54:03PM -0700, Ethan Jackson wrote:
> Sounds good, here is an incremental. I had to slightly modify test-bundle.c.
OK. Looks like trailing white space was the problem? You can avoid
that by putting @&t@ after the white space in the .at file. (But I
agree that actuall
Sounds good, here is an incremental. I had to slightly modify test-bundle.c.
---
tests/bundle.at | 133 ++-
tests/test-bundle.c |4 +-
2 files changed, 69 insertions(+), 68 deletions(-)
diff --git a/tests/bundle.at b/tests/bundle.at
index
That's what I had in mind, thanks.
On Fri, Jul 22, 2011 at 03:44:18PM -0700, Ethan Jackson wrote:
> Here is an incremental based on comments on a future patch.
>
> ---
> lib/nx-match.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/lib/nx-match.c b/lib
On Fri, Jul 22, 2011 at 01:36:26PM -0700, Ethan Jackson wrote:
> The mac-learning implementation used a free list to keep track of
> statically allocated table entries. This made the code slightly
> more difficult to understand than the more straightforward heap
> based strategy implemented by thi
Here is an incremental based on comments on a future patch.
---
lib/nx-match.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/lib/nx-match.c b/lib/nx-match.c
index b382b26..6c48d02 100644
--- a/lib/nx-match.c
+++ b/lib/nx-match.c
@@ -1224,12 +1224,17 @@ nxm_d
> Instead of removing the tests, would you mind changing them to try
> writing to a non-writable field?
Summary of an offline discussion:
This doesn't actually work because parse_flow does not check if the
field is in-fact writable. We could work around this, but we decided
to leave it.
Ethan
__
Before commit fa066f015 "bridge: Move packet processing functionality into
ofproto," the code that called into what became xlate_normal() prevented
a flow from being installed if it was called at revalidation time and
the MAC learning table lacked an entry for the flow's destination MAC.
That commi
I created this function because I thought I had three good use cases.
Unfortunately, one of them was wrong, so drop it.
---
lib/vlan-bitmap.h | 11 ++-
ofproto/ofproto-dpif.c |5 +++--
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/lib/vlan-bitmap.h b/lib/vlan-b
When a bit is set in flood_vlans, that VLAN must be flooded, but the logic
here was reversed in the case where there were any flooded VLANs at all.
Thus, if a single VLAN was configured to be flooded, all VLANs except that
one were actually flooded.
The common case where no VLANs were to be floode
Good idea, changed it.
Ethan
On Fri, Jul 22, 2011 at 15:24, Ben Pfaff wrote:
> On Fri, Jul 22, 2011 at 01:36:25PM -0700, Ethan Jackson wrote:
>> The mac-learning 'secret' parameter is intended to prevent an
>> attacker from turning the mac learning table into a linked list by
>> using a known ha
Sounds good.
Ethan
On Fri, Jul 22, 2011 at 15:06, Ben Pfaff wrote:
> On Fri, Jul 22, 2011 at 02:58:29PM -0700, Ethan Jackson wrote:
>> > ? ?Bonding only accepts multicast (and broadcast) packets on a single
>> > ? ?bond slave (the "active slave") at any given time. ?Multicast packets
>> > ? ?rec
On Fri, Jul 22, 2011 at 01:36:25PM -0700, Ethan Jackson wrote:
> The mac-learning 'secret' parameter is intended to prevent an
> attacker from turning the mac learning table into a linked list by
> using a known hash function to choose perfectly bad mac entries.
> However, this parameter was not ta
On Fri, Jul 22, 2011 at 02:58:29PM -0700, Ethan Jackson wrote:
> > ? ?Bonding only accepts multicast (and broadcast) packets on a single
> > ? ?bond slave (the "active slave") at any given time. ?Multicast packets
> > ? ?received on other slaves are dropped. ?Otherwise, every multicast
> > ? ?packe
I pushed this.
On Thu, Jul 21, 2011 at 03:52:52PM -0700, Ben Pfaff wrote:
> It could have caused unnecessarily flow revalidation. I don't think it
> could have caused real misbehavior.
>
> On Thu, Jul 21, 2011 at 03:42:18PM -0700, Ethan Jackson wrote:
> > Looks good.
> >
> > I'm curious, this c
Sounds good, I pulled your patch into the series as a replacement for mine.
Ethan
On Fri, Jul 22, 2011 at 10:25, Ben Pfaff wrote:
> On Thu, Jul 21, 2011 at 03:58:52PM -0700, Ethan Jackson wrote:
>> Calculates the position of the most significant bit in a 32 bit
>> word.
>
> I see that you've bee
> Bonding only accepts multicast (and broadcast) packets on a single
> bond slave (the "active slave") at any given time. Multicast packets
> received on other slaves are dropped. Otherwise, every multicast
> packet would be duplicated, once for every bond slave, because the
> phys
On Fri, Jul 22, 2011 at 02:48:40PM -0700, Ethan Jackson wrote:
> Nice patch, I always wondered why we locked the mac learning table
> entry in that case. SLB is kind of a mess.
>
> > + ? ? ?Open vSwitch avoids packet duplication by accepting multicast
> > + ? ? ?and broadcast packets on only the
Nice patch, I always wondered why we locked the mac learning table
entry in that case. SLB is kind of a mess.
> + Open vSwitch avoids packet duplication by accepting multicast
> + and broadcast packets on only the active slave, and dropping
> + multicast and broadcast packets on al
On Fri, Jul 22, 2011 at 2:22 PM, Ben Pfaff wrote:
> On Fri, Jul 22, 2011 at 2:18 PM, Jesse Gross wrote:
>> On Wed, Jul 13, 2011 at 10:05 PM, Valient Gough wrote:
>>> @@ -628,7 +768,8 @@ static int capwap_frag_match(struct inet_frag_queue
>>> *ifq, void *a_)
>>> struct frag_match *a = a_;
On Fri, Jul 22, 2011 at 2:18 PM, Jesse Gross wrote:
> On Wed, Jul 13, 2011 at 10:05 PM, Valient Gough wrote:
>> @@ -628,7 +768,8 @@ static int capwap_frag_match(struct inet_frag_queue
>> *ifq, void *a_)
>> struct frag_match *a = a_;
>> struct frag_match *b = &ifq_cast(ifq)->match;
On Wed, Jul 13, 2011 at 10:05 PM, Valient Gough wrote:
> diff --git a/datapath/vport-capwap.c b/datapath/vport-capwap.c
> index f0bb327..161c6d4 100644
> --- a/datapath/vport-capwap.c
> +++ b/datapath/vport-capwap.c
> +/*
> + * Should be sized as multiple of u32, for hash functions.
> + */
> stru
---
vswitchd/INTERNALS | 78
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/vswitchd/INTERNALS b/vswitchd/INTERNALS
index 6c1bdc1..86db369 100644
--- a/vswitchd/INTERNALS
+++ b/vswitchd/INTERNALS
@@ -129,3 +129,81 @@ least 0.1
We may want to backport this as well.
Ethan
On Fri, Jul 22, 2011 at 13:36, Ethan Jackson wrote:
> The mac-learning 'secret' parameter is intended to prevent an
> attacker from turning the mac learning table into a linked list by
> using a known hash function to choose perfectly bad mac entries.
The mac-learning implementation used a free list to keep track of
statically allocated table entries. This made the code slightly
more difficult to understand than the more straightforward heap
based strategy implemented by this patch.
---
lib/mac-learning.c | 23 +--
lib/ma
The mac-learning 'secret' parameter is intended to prevent an
attacker from turning the mac learning table into a linked list by
using a known hash function to choose perfectly bad mac entries.
However, this parameter was not taken into account in most cases.
Found by inspection.
---
lib/mac-lear
> We could get rid of the free list and the fixed array of mac_entries,
> replacing them by malloc() and free() and using hmap_count() to limit
> the number of entries. (When I wrote this code I had a notion that we
> might want to avoid malloc() entirely in OVS, at least after startup. I
> don't
On Thu, Jul 21, 2011 at 03:58:55PM -0700, Ethan Jackson wrote:
> The bundle_load action behaves the same as the bundle action,
> except instead of outputting, it writes its result to a register.
The update to the comment on nx_action_multipath could have gone into
the commit that generalized the m
On Thu, Jul 21, 2011 at 03:58:54PM -0700, Ethan Jackson wrote:
> I don't expect this bundling algorithm to be particularly useful in
> software switches. However, hardware switches will probably only
> support this bundling algorithm, so it's implemented here as an
> example and a reference.
Look
On Thu, Jul 21, 2011 at 03:58:53PM -0700, Ethan Jackson wrote:
> This patch creates two new helper functions, nxm_reg_load() and
> nxm_dst_check(). The new nxm_dst_check() function may be used to
> check the validity of destination fields used by actions. The new
> nxm_reg_load() function may be
On Thu, Jul 21, 2011 at 03:58:52PM -0700, Ethan Jackson wrote:
> Calculates the position of the most significant bit in a 32 bit
> word.
I see that you've been reading _Hacker's Delight_.
This solution is unnecessarily slow on common machines (like 80x86) that
can calculate log_2_floor() in one o
On Thu, Jul 21, 2011 at 03:58:51PM -0700, Ethan Jackson wrote:
> This has been helpful finding bugs in my development environment.
> It's good to exercise this code.
Yes, I agree that this is a good idea. Thank you.
___
dev mailing list
dev@openvswitch.
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, Jul 21, 2011 at 06:18:01PM -0700, Ethan Jackson wrote:
> The mac-learning code predates the hmap data structure in OVS. For
> this reason, it rolled it's own hmap-like bucket concept. This
> patch converts it to use an hmap which makes the code slightly
> simpler and easier to understand.
hello My Dear,
i am miss esther,i would like to know more about you,please contact me through
(esther_n...@yahoo.com) fomer to explain myself and send my pics for you to
know me.Best regards
esther
___
dev mailing list
dev@openvswitch.org
http://o
40 matches
Mail list logo
