[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 02 Feb 2011 09:30:02 -0800
From: Jay Vosburgh <fubar@...ibm.com>
To: "Oleg V. Ukhno" <olegu@...dex-team.ru>
cc: Nicolas de Pesloüan
<nicolas.2p.debian@...il.com>,
John Fastabend <john.r.fastabend@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
Oleg V. Ukhno <olegu@...dex-team.ru> wrote:
>On 01/29/2011 05:28 AM, Jay Vosburgh wrote:
>> Oleg V. Ukhno<olegu@...dex-team.ru> wrote:
>>
>> I've thought about this whole thing, and here's what I view as
>> the proper way to do this.
>>
>> In my mind, this proposal is two separate pieces:
>>
>> First, a piece to make round-robin a selectable hash for
>> xmit_hash_policy. The documentation for this should follow the pattern
>> of the "layer3+4" hash policy, in particular noting that the new
>> algorithm violates the 802.3ad standard in exciting ways, will result in
>> out of order delivery, and that other 802.3ad implementations may or may
>> not tolerate this.
>>
>> Second, a piece to make certain transmitted packets use the
>> source MAC of the sending slave instead of the bond's MAC. This should
>> be a separate option from the round-robin hash policy. I'd call it
>> something like "mac_select" with two values: "default" (what we do now)
>> and "slave_src_mac" to use the slave's real MAC for certain types of
>> traffic (I'm open to better names; that's just what I came up with while
>> writing this). I believe that "certain types" means "everything but
>> ARP," but might be "only IP and IPv6." Structuring the option in this
>> manner leaves the option open for additional selections in the future,
>> which a simple "on/off" option wouldn't. This option should probably
>> only affect a subset of modes; I'm thinking anything except balance-tlb
>> or -alb (because they do funky MAC things already) and active-backup (it
>> doesn't balance traffic, and already uses fail_over_mac to control
>> this). I think this option also needs a whole new section down in the
>> bottom explaining how to exploit it (the "pick special MACs on slaves to
>> trick switch hash" business).
>>
>> Comments?
>>
>> -J
>>
>Jay,
>As for me splitting my initial proposal into two logically diffent pieces
>is ok, this will provide more flexible configuration.
>Do I understand correctly, that after I rewrite patch in splitted form,
>as you described above, and enhance documentation it will be /can be
>applied to kernel?
Yes, although the patches may have to go through a few
revisions.
>Then what should I do: rewrite patch and resubmit it as a new one?
Yes.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists