Thanks for confirming the fix. I'll take a look at the second patch
then.
On Thu, Jan 03, 2013 at 05:15:35PM +, Zoltan Kiss wrote:
> Hi,
>
> I've tested with your fix (865f22b3b3cb9), and it solves the problem
> indeed. My approach to fix the problem is based on the comment of
> the tag memb
Hi,
I've tested with your fix (865f22b3b3cb9), and it solves the problem
indeed. My approach to fix the problem is based on the comment of the
tag member:
/* A hash bucket for mapping a flow to a slave.
* "struct bond" has an array of (BOND_MASK + 1) of these. */
struct bond_entry {
stru
Oh, also you said you tested it against OVS 1.4.2, but not against
1.4.3, which has an important relevant fix as commit 865f22b3b3cb9
(bond: Tag flows according to their hash bucket, not just their slave.).
It's always best to test against the latest version in whatever branch
you're using.
On Mon
The patch doesn't entirely add up. I've been intending to test the
behavior myself, but with the holidays and other stuff I have to do, I
haven't managed it yet.
On Mon, Dec 31, 2012 at 03:48:12PM +, Zoltan Kiss wrote:
> Hi,
>
> Did you guys had any chance to check this patch? (and the one
>
Hi,
Did you guys had any chance to check this patch? (and the one related in
the next mail)
Btw. the numbering in the subject is wrong, it should be [PATCH 1/2].
Zoli
On 20/12/12 21:39, Zoltan Kiss wrote:
As the description of this field states, it should link the hash entry
to the slave. Wi
As the description of this field states, it should link the hash entry
to the slave. With random tags, the flow revalidation never finds the
corresponding facet after bond rebalancing, therefore the flow
entries never get updated.
I've tested it on Xenserver 6.1 (OVS 1.4.2), two NIC with LACP bondi